Campinas 2019 Universidade Estadual De Campinas

UNIVERSIDADE ESTADUAL DE CAMPINAS Faculdade de Engenharia Elétrica e de Computação

RAMON CRAVO FERNANDES

ARES: UM PROCESSO CENTRADO EM MODELAGEM PARA PESQUISA APLICADA EM ENGENHARIA

CAMPINAS 2019

RAMON CRAVO FERNANDES

ARES: UM PROCESSO CENTRADO EM MODELAGEM PARA PESQUISA APLICADA EM ENGENHARIA

Dissertação de Mestrado

apresentada à Faculdade de Engenharia Elétrica e de Computação da Universidade Estadual de Campinas para obtenção do título de Mestre em Engenharia Elétrica, na área de

Engenharia Biomédica.

Orientador: Prof. Dr. Eduardo Tavares Costa

ESTE TRABALHO CORRESPONDE À

VERSÃO FINAL DA DISSERTAÇÃO DEFENDIDA PELO ALUNO RAMON CRAVO FERNANDES, E ORIENTADA PELO PROF. DR. EDUARDO

TAVARES COSTA

CAMPINAS 2019

COMISSÃO JULGADORA – DISSERTAÇÃO DE MESTRADO

Candidato: Ramon Cravo Fernandes RA: 142386

Data da Defesa: 20 de fevereiro de 2019

Título da Tese: “ARES: Um processo centrado em modelagem para pesquisa aplicada em engenharia”

Prof. Dr. Eduardo Tavares Costa (Presidente) Prof. Dr. Eduardo Jorge Valadares Oliveira Prof. Dr. José Wilson Magalhães Bassani

A ata de defesa, com as respectivas assinaturas dos membros da Comissão Juldadora, encontra-se no SIGA (Sistema de Fluxo de Dissertação/Tese) e na Secretaria de Pós-Graduação da Faculdade de Engenharia Elétrica e de Computação

RESUMO

A inovação enquanto sistema constrói-se sobre as relações entre seus agentes, materializada pelas trocas e transferências de conhecimento e tecnologias. Neste contexto, a pesquisa torna-se parte do sistema de inovação, e a produção de conhecimento um empreendimento de facto. Assim, o empreendedorismo acadêmico é um processo de internalização das atividades de transferência tecnológica e de conhecimento. Na tentativa de abordar as questões referentes à gestão de interfaces entre os produtores de conhecimento e tecnologia (universidades, organizações e centros de pesquisa e desenvolvimento, etc.) e os demais atores da inovação, suas interdependências e iteratividades, esta dissertação apresenta o desenvolvimento de um processo centrado em modelagem e simulação, denominado processo ARES. Direcionado para a pesquisa aplicada em engenharia, o processo ARES é um processo incremental-evolutivo, baseado em transições uniformes e suaves de modelos mentais do domínio do problema para modelos de sistema e, assim, para modelos de design e implementação. De forma que, durante o desenvolvimento de um sistema ou pesquisa, os conhecimentos gerados ou empregados em seu esforço são adquiridos, selecionados, armazenados e transferidos através de mecanismos explícitos do processo, dando suporte à gestão do conhecimento, atributo da capacidade motriz de inovação de uma organização.

Palavras-chave: Engenharia de sistemas, Inovação, Pesquisa aplicada de engenharia, Processo ARES.

ABSTRACT

Innovation as a system is built on the relationship between its agents, materialized by the exchange and transfer of knowledge and technologies. In this context, research become part of the innovation system, and the production of knowledge an enterprise de facto. Consequently, academic entrepreneurship is a process of internalization of the activities of knowledge and technological transfer. In a bid to address the issues of interface management between knowledge and technology producers (universities, organizations and centers of research and development, etc.) and the other actors of innovation, their interdependencies and iterations, this dissertation presents the development of a model-centric process, called ARES. Targeting applied research in engineering science, ARES is an incremental- evolutionary process, based on seamless and smooth transitions from mental models of the problem domain to system models, and thus to design and implementation models. Therefore, during the development of a system or research, the knowledge generated or employed in its effort is acquired, selected, stored and transferred through explicit mechanisms within ARES, supporting knowledge management, attribute of the innovation driving power of an organization.

Keywords: Systems engineering, Innovation, Applied research in engineering science, ARES process.

LISTA DE FIGURAS

Figura 2.1 - Modelo dinâmico do quadrante de Pasteur ...... 22 Figura 2.2 - Fase 1 do modelo hélice tripla...... 24 Figura 2.3 - Fase 2 do modelo hélice tripla...... 25 Figura 2.4 - Fase 3 do modelo hélice tripla...... 27 Figura 2.5 - Modelo de triangulação da hélice tripla ...... 30 Figura 2.6 - Relação entre engenharia, scientia, techné e praxis ...... 34 Figura 2.7 - Interação entre engenharia, ciência e organizações industriais e empresariais ...... 35 Figura 2.8 - Relação engenharia/ciência ...... 37 Figura 2.9 - Relação engenharia/organizações industriais e empresariais ...... 38 Figura 3.1 - Fases e atividades da metodologia OOSEM ...... 42 Figura 3.2 - O processo FDD ...... 57 Figura 4.1 - Estratégia de design do processo ARES ...... 67 Figura 4.2 - Primeira abstração do processo ARES ...... 69 Figura 4.3 - Segunda abstração do processo ARES ...... 70 Figura 4.4 - Terceira abstração do processo ARES ...... 72 Figura 4.5 - Quarta abstração do processo ARES ...... 73 Figura 5.1 - O processo ARES ...... 86 Figura 5.2 - Modelo Rugby ...... 93 Figura 5.3 - Níveis de abstração no domínio da modelagem ...... 95 Figura 5.4 - Exploração: Modelagem cognitiva e Análise preliminar ...... 102 Figura 5.5 - Análise: Modelagem e validação conceitual ...... 107 Figura 5.6 - Arquitetura: Modelagem, especificação e validação sistêmica ...... 112 Figura 5.7 - Arquitetura: Design da arquitetura e Particionamento ...... 118 Figura 5.8 - Design: Encapsulamento e validação do design ...... 124 Figura 5.9 - Implementação e teste: Implementação, verificação e validação de implementação e de pesquisa ...... 129 Figura 5.10 - Extração de propriedades essenciais por simplificações/abstrações sucessivas ...... 133

Figura 5.11 - Representação de domínio específico das pontes de Königsberg 135 Figura 5.12 - Esforço de modelagem do processo ARES ...... 143 Figura 5.13 - Natureza dos modelos mentais ...... 146 Figura 5.14 - Co-design: Modelagem homogênea ...... 153 Figura 5.15 - Processo de aquisição de conhecimento de especialistas de domínio ...... 157 Figura 6.1 - Modelo mental da natureza e física da formação de imagens modo-B ...... 166 Figura 6.2 - Formação de imagens por ultrassom focalizado ...... 167 Figura 6.3 - Esboço da arquitetura da plataforma de ultrassonografia diagnóstica ...... 170 Figura 6.4 - Modelo conceitual do sistema ...... 174 Figura 6.5 - Framework FBS situado ...... 181 Figura 6.6 - Modelo em "caixa cinza": Decomposição do sistema em suas macro- funções ...... 185 Figura 6.7 - Estrutura ontológica do catálogo de soluções ...... 187 Figura 6.8 - Diagrama lógico do sistema-solução ...... 190 Figura 6.9 - Estratégia Pipeline ...... 194 Figura 6.10 - Arquitetura geral das FPGAs Virtex-6 ...... 195 Figura 6.11 - Diagrama de blocos de núcleo DSP C66x ...... 197 Figura 6.12 - Diagrama da arquitetura da plataforma ...... 202 Figura 6.13 - Modelo encapsulado: Topologia e mapeamento dos filtros FIR na tecnologia alvo ...... 206 Figura 6.14 - Modelo encapsulado: Implementação do algoritmo não-restaurativo de raiz quadrada ...... 208 Figura 6.15 - Modelo encapsulado: Lógica de carry ...... 209 Figura 6.16 - Modelo encapsulado: Decimador ...... 210 Figura 6.17 - Imagem ultrassônica gerada pela plataforma a partir do phantom CIRS 068 ...... 213 Figura 6.18 - Imagens ultrassônicas em tempo real obtidas pela plataforma ..... 214

LISTA DE QUADROS

Quadro 3.1 - Dimensões do framework RUP SE ...... 47 Quadro 5.1 - Níveis de interoperabilidade conceitual LCIM ...... 88 Quadro 5.2 - Papéis descritivos e prescritivos dos níveis do framework LCIM .... 90

SUMÁRIO

1 CONSIDERAÇÕES INICIAIS ...... 14

1.1 OBJETIVOS ...... 15 1.2 MÉTODO DA PESQUISA ...... 16 1.2.1 Análise ...... 16 1.2.2 Design ...... 17 1.2.3 Implementação ...... 18 1.2.4 Teste ...... 18 1.3 ESTRUTURA DO TRABALHO ...... 19

2 INOVAÇÃO, CIÊNCIA E TECNOLOGIA ...... 21

2.1 O MODO 2 ...... 22 2.2 A HÉLICE TRIPLA ...... 23 2.2.1 As fases do modelo ...... 23 2.2.2 O papel das instituições ...... 28 2.3 O QUE É ENGENHARIA? ...... 32 2.3.1.1 Engenharia, ciência e indústria ...... 34

3 PROBLEMATIZAÇÃO ...... 39

3.1 ANÁLISE E INVESTIGAÇÃO ...... 40 3.1.1 Object-Oriented Systems Method (OOSEM) ...... 40 3.1.1.1 Análise e características da metodologia OOSEM ...... 44 3.1.2 Rational Unified Process for System Engineering (RUP SE)...... 46 3.1.2.1 Metodologia use-case flowdown ...... 51 3.1.2.2 Análise e características do framework RUP SE ...... 52 3.1.3 Feature-Driven Development (FDD) ...... 55 3.1.3.1 Análise e características do processo FDD ...... 60 3.2 CARACTERÍSTICAS DESEJÁVEIS À INOVAÇÃO ...... 61

4 ARQUÉTIPO E DESIGN DO PROCESSO ARES ...... 65

4.1 DESIGN HÍBRIDO ...... 67

4.2 PROGRESSÃO DO DESIGN ...... 69 4.2.1 O arquétipo do processo ARES ...... 74 4.2.1.1 Modelagem cognitiva e plano de desenvolvimento preliminar ...... 75 4.2.1.2 Modelagem conceitual e engenharia de requisitos...... 76 4.2.1.3 Modelagem e especificação do sistema ...... 77 4.2.1.4 Particionamento e design da arquitetura do sistema ...... 79 4.2.1.5 Desenvolvimento incremental/evolutivo ...... 79 4.2.1.6 Transição ...... 80 4.3 O DESIGN SOB A ANÁLISE DOS REQUISITOS ...... 81

5 O PROCESSO ARES ...... 84

5.1 FRAMEWORKS USADOS NO PROCESSO ARES ...... 87 5.1.1 LCIM ...... 87 5.1.2 Rugby ...... 93 5.1.3 Triângulo de Couclelis ...... 97 5.2 O PROCESSO ARES DESCRITO SOB A PERSPECTIVA DE SUAS ATIVIDADES ...... 101 5.2.1 Modelagem cognitiva e plano de desenvolvimento preliminar ... 101 5.2.2 Modelagem conceitual e validação conceitual ...... 106 5.2.3 Modelagem e especificação do sistema e validação sistêmica .. 111 5.2.4 Design da arquitetura do sistema e particionamento ...... 117 5.2.5 Encapsulamento e validação do design ...... 122 5.2.6 Implementação, verificação e validação da implementação e validação e transferência da pesquisa ...... 128 5.3 O PROCESSO ARES DESCRITO SOB A PERSPECTIVA DO ESFORÇO DE MODELAGEM 132 5.3.1 O propósito de um modelo ...... 135 5.3.2 Transformação de modelo ...... 136 5.3.3 Validação de modelos ...... 138 5.3.3.1 Critérios de validade gerencial de modelos ...... 138 5.3.4 O esforço de modelagem ...... 141 5.3.4.1 Modelagem cognitiva ...... 144 5.3.4.2 Modelagem conceitual ...... 147

5.3.4.3 Modelagem sistêmica ...... 149 5.3.4.4 Modelagem do sistema-solução ...... 150 5.3.4.5 Modelagem da arquitetura do sistema ...... 151 5.3.4.6 Modelagem do design do sistema ...... 152 5.3.4.7 Modelagem da implementação do sistema ...... 153 5.4 O PROCESSO ARES DESCRITO SOB A PERSPECTIVA DA GESTÃO DO CONHECIMENTO ...... 154 5.4.1 Estratégias da gestão do conhecimento associada ao processo ARES 154 5.4.1.1 Identificação...... 155 5.4.1.2 Aquisição ...... 156 5.4.1.3 Seleção e validação ...... 159 5.4.1.4 Organização e armazenagem ...... 161 5.4.1.5 Compartilhamento...... 161 5.4.1.6 Aplicação ...... 162 5.4.1.7 Criação ...... 163

6 CASO DE ESTUDO ...... 164

6.1 O PROJETO PROTO85 ...... 165 6.1.1 Modelagem cognitiva ...... 165 6.1.2 Modelagem conceitual ...... 172 6.1.3 Modelagem sistêmica e do sistema-solução ...... 177 6.1.3.1 Framework FBS situado...... 178 6.1.3.2 O resultado da modelagem sistêmica e do sistema-solução e a estrutura ontológica do catálogo de soluções ...... 184 6.1.4 Arquitetura, design e implementação do sistema ...... 192 6.1.4.1 Modelo da abstração de tecnologia ...... 199 6.1.4.2 Particionamento, encapsulamento e implementação ...... 203 6.1.5 Validação e transferência do conhecimento ...... 212 6.2 O PROCESSO ARES SOB A ANÁLISE DOS REQUISITOS ...... 215

7 CONSIDERAÇÕES FINAIS ...... 218

7.1 ARTIGOS PUBLICADOS ...... 220

REFERÊNCIAS ...... 223

ANEXO A ...... 243

1 CONSIDERAÇÕES INICIAIS

Nas últimas décadas, a teoria da inovação, ciência e tecnologia têm se expandido e avançado nas definições quanto a sua natureza, processos e interrelações. Intimamente relacionados entre si, os atores participantes do processo de inovação constroem um círculo virtuoso de saber interdisciplinar. Sempre que mudanças socioeconômicas ou culturais ocorrem, o processo de inovação, ciência e tecnologia se altera de acordo, conduzindo à evolução de seu entendimento, fundamentos e modelos que, por sua vez, contribuem para sua condução e realização. Neste sentido, como observa Dudziak (2007), há uma inerente ligação dialética1 entre a teoria da inovação, ciência e tecnologia, a práxis acadêmica de pesquisa e as intervenções no processo empreendidas pelo poder público, e que apenas uma visão harmonizada desses três fatores produz um sistema de inovação. Da práxis acadêmica elegeu-se o objeto desta dissertação, um processo de pesquisa e desenvolvimento voltado para a inovação, na qual, busca-se estabelecer uma relação entre as prerrogativas da inovação e a pesquisa aplicada em engenharia, elencando as características e requisitos desejáveis à inovação, sob a ótica da pesquisa continuada e do avanço tecnológico. A aparente inabilidade ou incapacidade dos processos e metodologias disponíveis, principalmente nos ditos ágeis, em suportar a pesquisa continuada ou em assistir a interdisciplinaridade crescente nos empreendimentos de avanço tecnológico e inovação, foi o motivador e motor do presente trabalho. Um olhar mais atento sobre os processos e metodologias de desenvolvimento de software e sistemas mostra inúmeras omissões e deficiências (NUSEIBEH; EASTERBROOK, 2000; PAIGE; OSTROFF, 2002; BOEHM, 2006), incluindo: • Precária rastreabilidade entre requisitos e a coisa. • A inconsistência entre artefatos.

1 Entende-se aqui a dialética no sentido de Hegel (HEGEL, 1998), com a compreensão de que o conflito entre opostos não é ideal, mas real, e que a superação dessa disputa não representa uma correção no conteúdo, mas o surgimento de algo novo (FERREIRA, 2013), sob a tríade Abstrato- Negativo-Concreto.

• A adoção de premissas e pressupostos não realistas, especialmente nas metodologias ágeis. • O desenvolvimento contínuo não é adequadamente apreciado. • A inconsistência dos artefatos nas metodologias guiadas ou baseadas em modelos. • O vínculo patente com a disciplina da engenharia de software. • Ausência de vínculo entre a estrutura dos processos e metodologias e gestão do conhecimento.

1.1 OBJETIVOS

Da motivação, pode-se resumir o esforço empregado neste trabalho como: A criação de um processo, chamado ARES, centrado na modelagem e simulação para pesquisa aplicada em engenharia através de um processo genérico de desenvolvimento de sistemas, analisando processos, meta-processo e metodologias existente, extraindo suas características básicas e produzindo um conjunto de requisitos que define as propriedades que o processo alvo deve atender. A metodologia pode então ser projetada e implementada a partir de técnicas de especificação existentes de forma a satisfazer os requisitos. Os objetivos específicos que devem ser alcançados pelo processo ARES estão detalhados na seção 3.2, características desejáveis à inovação, e podem ser resumidos em: • Criação de um processo que contemple explicitamente a gestão do conhecimento • Criação de uma cadeia de atividades e artefatos uniforme e rastreável • Criação de um processo independente de linguagens ou ferramentas específicas • Criação de uma cadeia de validação contínua dos artefatos gerados no ciclo de vida do processo.

1.2 MÉTODO DA PESQUISA

Uma vez que este trabalho visa o desenvolvimento de um processo, o que poder-se-ia considerar por método aplicável? Na abordagem desta dissertação, o desenvolvimento do processo centrado na modelagem e simulação para pesquisa aplicada em engenharia (processo ARES) foi aproximado ao desenvolvimento de um sistema ou software de domínio-específico. Desta forma, o processo empregado consiste de quatro fases comuns ao desenvolvimento de sistemas de domínio- específico e similares àquelas empregas pela engenharia de software: Análise, Design, Implementação e Teste; abordagem proposta por Ramsin em sua tese, The Engineering of an Object-Oriented Software Development Methodology (RAMSIN, 2006). Nesta abordagem o processo é desenvolvido através de um ciclo iterativo de design, implementação e teste com base no resultado da análise. Ao final de cada fase e de cada ciclo, uma atividade complementar de verificação e revisão do processo é realizada, garantindo um esforço coerente de desenvolvimento.

1.2.1 Análise

As atividades e os objetivos na fase de Análise focam na descoberta e análise dos requisitos, através da exploração do domínio do problema. No escopo desse trabalho, listam-se os seguintes objetivos como os principais dessa fase: • Identificação e análise detalhada do domínio do problema; extrair as características essenciais para a identificação dos requisitos para o processo através da compreensão das estruturas e comportamentos do domínio do problema. • Definição dos critérios de análise; produzir os requisitos do processo através da aplicação dos critérios de análise ao domínio do problema. • Determinar o escopo do processo e delinear os requisitos aplicáveis. Abaixo enumera-se um possível conjunto de atividades que satisfazem os principais objetivos da fase de Análise:

Atividade 1: Exploração do domínio do problema, abrangendo o estudo e a análise das metodologias e processos existentes, elencando os atributos de cada metodologia, levando, por sua vez, as características desejáveis ao processo proposto; esta tarefa é a base para a concepção de um conhecimento analítico sobre processos e metodologias, pré-requisito para a elaboração de um conjunto confiável de requisitos de processo e de um método adequado para arquitetar o processo proposto. Atividade 2: Composição de um conjunto de requisitos concretos, a que deve obedecer ao processo proposto; esta tarefa requer uma análise das metodologias existentes.

1.2.2 Design

Análogo a engenharia de software, a fase de Design refere-se à produção de uma especificação detalhada para o software em desenvolvimento, que, no escopo desta dissertação trata-se do processo ARES, a ser implementada nas fases posteriores. Os objetivos dessa fase são: • Desenvolvimento de um arquétipo para o processo proposto. • Produção de uma especificação detalha para o processo alvo baseada no processo e nos requisitos. As atividades que compõem a fase de Design são: Atividade 3: Adução do arquétipo para projetar o processo com base na compreensão e conhecimentos acumulados sobre o domínio do problema e nos requisitos descobertos a partir deste. Atividade 4: Concepção do processo alvo através da aplicação do arquétipo selecionado; o produto desta fase inclui o esqueleto do processo alvo, com sua arquitetura, fases, e subfases, fornecendo indicações de atividades e tarefas numa dada ordem, especificando quais artefatos devem ser produzidos em cada fase.

1.2.3 Implementação

Esta fase trata do desenvolvimento do processo em si. Tal qual a noção de implementação aplicada no desenvolvimento de softwares e sistemas, essa fase produz o processo e o disponibiliza ao usuário. No contexto dessa dissertação, a implementação tem por objetivos: • Produção do processo através do detalhamento das especificações da fase de Design. • Disponibilização do processo aos usuários. As atividades que constituem a implementação são: Atividade 5: Produção da documentação necessária ao uso do processo alvo com sua especificação detalhada descrevendo suas fases, processos e métodos.

1.2.4 Teste

A fase de teste de um processo não difere muito dos testes aplicados a sistemas, o principal objetivo de um teste é verificar e validar o produto e suas características. A fase de teste para o desenvolvimento do processo tem por objetivos: • Aplicação do processo a um caso de estudo. • Análise, verificação e validação a aderência do processo ao caso de estudo proposto. As atividades dessa fase são: Atividade 6: Definição do caso de estudo; seus requisitos, escopo e características próprias. Atividade 7: Validação do processo através da análise do fluxo de desenvolvimento e obtenção do produto final definido no escopo do caso de estudo.

1.3 ESTRUTURA DO TRABALHO

Esta dissertação foi organização de maneira pouco ortodoxa com a finalidade única de tornar a descrição do processo ARES (apresentada no Capítulo 5) completa e autocontida num capítulo independente e de que cada fase do processo de seu desenvolvimento esteja contida em um capítulo dedicado. Assim, todo e cada pedaço de informação pertinente ao processo e ao seu desenvolvimento encontra-se oportuno em seu capítulo correspondente. Dessa maneira, segue-se: • No Capítulo 1 (Consideração Iniciais) é feita uma pequena introdução, apresentando o contexto geral que permeará toda a dissertação, a motivação, objetivos e método aplicado no desenvolvimento do processo ARES. • No Capítulo 2 (Inovação, Ciência e Tecnologia) são apresentados os fundamentos teóricos de um sistema de inovação. Com o objetivo de lançar luz sobre os atores e componentes de um sistema de inovação e suas relações e interdependências, este capítulo foi estruturado para apresentar o contexto específico no qual se insere o processo desenvolvido. • No Capítulo 3 (Problematização) um cânone de metodologias de engenharia de sistemas é investigado, correspondendo à fase de Análise do desenvolvimento do processo ARES. Ao final deste capítulo lista-se um conjunto de características e requisitos desejáveis à inovação. • No Capítulo 4 (Arquétipo e Design do Processo ARES) discute-se sobre o processo de desenvolvimento iterativo aplicado na fase de Design do desenvolvimento do processo ARES, seus mecanismos e resultados. O processo é gradualmente formado a cada iteração, resultando num arquétipo, cujas interfaces entre fases e macro-atividades são suficientemente detalhadas, delineado no final do capítulo. • O Capítulo 5 (O Processo ARES) apresenta o processo ARES em si, e corresponde à fase de Implementação do processo. Neste capítulo o processo ARES é descrito detalhadamente sob três perspectivas singulares – das atividades, do esforço de modelagem e da gestão do conhecimento –

englobando, em cada uma delas, os conceitos, premissas e visões particulares. • No Capítulo 6 (Caso de Estudo), referente à fase de Teste do processo, o caso de estudo, denominado projeto Proto85, no qual o processo ARES foi aplicado, é apresentado. Para cada subprocesso do processo ARES, os principais resultados, decisões e artefatos são apresentados, evidenciando o vínculo e a coerência entre estes e a cadeia de desenvolvimento proposto pelo processo. Ao final do capítulo o processo ARES é analisado quanto aos seus requisitos. • No Capítulo 7 (Considerações Finais) são apresentadas as conclusões parciais do esforço inicial empregado no desenvolvimento do processo ARES, contendo um sumário das principais contribuições e resultados alcançados com o desenvolvimento do processo e uma lista de cursos potenciais (sugestões de encaminhamento) para o aprofundamento e complementação de alguns de seus aspectos. • Referências finalizam o trabalho.

2 INOVAÇÃO, CIÊNCIA E TECNOLOGIA

A inovação enquanto processo evolucionário de interação entre mercado e a base de conhecimentos e capacidades das empresas (PORTER, 1990) considera por base uma visão gerencial estratégica. Nesta perspectiva é preciso considerar, por um lado, a trajetória da empresa, sua estratégia tecnológica e seu sistema de gestão e, por outro lado, fatores externos, como o contexto econômico, a variabilidade intra- e intersetorial, a organização do mercado, a localização geográfica, etc. A inovação enquanto sistema constrói-se sobre as relações entre seus agentes, materializada pelas trocas e transferências de conhecimentos e tecnologias, considerando a capacidade que os atores possuem em transformar ações em bens econômicos (CARLSSON et al., 2002), definida como competência tecno-econômica de ênfase estratégica (DUDZIAK, 2007). Para Metcalfe (2003), um sistema de inovação é tal um conjunto de instituições distintas que juntas e individualmente contribuem para o desenvolvimento e difusão de novas tecnologias e que provê a estrutura dentro da qual governos formam e implementam políticas para influenciar o processo de inovação. Como tal, é um sistema de instituições interconectadas para criar, estocar e transferir conhecimento, habilidades e artefatos os quais definem novas tecnologias. A pesquisa e a investigação científica, encarada como uma forma de resolver problemas, torna-se atividade adjunta, parte da cadeia de inovação e não mais pré- condição de sua iniciativa. Segundo Dudziak (2007), neste momento, a atividade de pesquisa abandona seu isolamento acadêmico e torna-se parte do sistema de ciência, tecnologia e inovação. Para Stokes (1997), não existe, de fato, uma oposição entre as ciências, em suas pesquisas básicas e aplicadas, mas uma visão diferente a respeito da motivação que leva à pesquisa, quer seja orientada pela necessidade de entendimento, pela necessidade de uso ou ambos. O que o autor chama de quadrante de Pasteur, cuja representação dinâmica é representada na figura 2.1.

Figura 2.1 - Modelo dinâmico do quadrante de Pasteur

Fonte: STOKES, 1997

Neste contexto, trata-se, portanto, de determina que valor uma pesquisa possui: científico, econômico, social ou tecnológico.

2.1 O MODO 2

Do ponto de vista em que o conhecimento somente é produzido em um contexto de aplicação e em que se encontra influenciado pelos interesses de diversos agentes sociais, Gibbons et al. (1994) sumarizaram a transformação do paradigma de produção de conhecimento, no que se convencionou chamar de “modo 2” de produção. O “modo 2” diferencia-se por considerar a transdisciplinaridade e o entendimento de que o conhecimento é produzido no

23 contexto de sua aplicação, é socialmente distribuído, heterogêneo, variável e cujos mecanismos de comunicação são mais densos e horizontais. Nessa abordagem, a visão da ciência como saber puro é substituída por uma ciência baseada na força produtiva, condicionada pelas estruturas sociais que moldam seu curso, métodos e resultados (VELHO, 1996), tornando-se socialmente relevante a partir de seu impacto econômico, legitimadora de mudanças tecnológicas, cujo ápice encontra-se no mundo empresarial.

2.2 A HÉLICE TRIPLA

No mesmo raciocínio do “modo 2” de produção, porém com foco nos relacionamentos entre atores, surge o modelo teórico de inovação: o modelo da hélice tripla de Etzkowitz e Leydesdorff (1995). O modelo da hélice tripla representa as relações entre universidades (entendidas aqui como entidades de ensino e pesquisa), empresas e governo, articulando redes de comunicação e trocas, conhecimentos e sistemas envolvidos em ciência, tecnologia e inovação. O modelo da hélice tripla compreende três estágios/fases distintas: primeiro, um papel proeminente da universidade na inovação; segundo, um movimento em torno das relações colaborativas entre as três esferas institucionais – as políticas de inovação são construídas a partir das interações entre os três agentes; terceiro, a sobreposição de funções e desenvolvimento em diferentes eixos retro-alimentadores (DUDZIAK, 2007) – a universidade é formadora de empresas e também exerce papel como fornecedora de pessoas e serviços.

2.2.1 As fases do modelo

Num processo de desenvolvimento econômico com base em dinâmicas do tipo hélice tripla, é possível identificar, como dito anteriormente, três fases distintas, baseadas nas estruturas funcionais de cada uma das esferas e na forma como interagem.

FASE 1: O modelo político

Figura 2.2 - Fase 1 do modelo hélice tripla

Fonte: ETKOWITZ; LEYDESDORFF, 2000 (Reproduzido com autorização)

No arranjo institucional tradicional, predominante até meados do século vinte, as três esferas evidenciam fronteiras bem definidas e sem sobreposições, com funções próprias bem delimitadas (ETZKOWITZ; LEYDESDORFF, 2000): a universidade produz ciência fundamental e ensina; a indústria produz. Os novos produtos resultam do desenvolvimento experimental na esfera da indústria; o governo regula e regimenta o funcionamento da universidade e da indústria e as relações entre elas (Figura 2.2). As relações entre universidade e indústria processa-se no nível do ensino, com a consideração da necessidade de adaptação da oferta de mão de obra especializada (formação acadêmica) às necessidades do mercado de trabalho. O governo alinha-se cada vez mais a um nível internacional, na contínua necessidade de adaptação a um mundo em constante mutação, implicando na necessidade de constante mudança, análise, avaliação e adaptação dos objetivos no tocante a informações disponíveis e resultado pretendidos (AUXILIAR, 2010). Neste contexto, a aproximação do governo às duas outras esferas institucionais é inevitável.

As mudanças que se vão processando no interior das diferentes esferas institucionais e no meio em que operam, imperam a reestruturação das estruturas organizacionais e institucionais e da mentalidade e o estreitamento das relações prevalecentes. É este ciclo de mudanças que impulsiona o sistema de inovação para a fase seguinte. FASE 2: O modelo laissez-faire

Figura 2.3 - Fase 2 do modelo hélice tripla

Fonte: ETZKOWITZ; LEYDESDORFF, 2000 (Reproduzido com autorização)

Nesta fase, as hélices do sistema se redefinem como sistemas de comunicações que consistem no funcionamento do mercado, na tecnologia e no controle existentes sobre as interfaces (ETZKOWITZ; LEYDESDORFF, 2000). As reestruturações internas de cada um dos agentes e o aprofundamento das relações bilaterais, gera um aumento da circulação de informações entre as esferas (Figura 2.3). À medida que a rede relacional toma forma e se consolida, novas transformações ocorrem em cada uma das esferas institucionais. A pressão exercida sobre as universidades em termos de autonomia financeira, e a decorrente orientação para o mercado, faz com que adquiram competências empreendedoras: • Numa filosofia de prestação de serviços e captação de financiamento, acordos de pesquisa e investigação acadêmica são estabelecidos entre universidade e indústria.

• O sistema de controle da qualidade da produção científica passa a ser feito por avaliadores acadêmicos e empresariais. Ao envolver a indústria, esta avaliação permite uma correção de trajetória quando existe um desvio de objetivo, cada vez mais orientada à indústria. • Aumento da autonomia dos centros de pesquisas que passa a ser geridos de acordo com objetivos sociais e organizacionais. A aceitação da importância das interrelações entre as três esferas gera uma aproximação entre governo, universidade e indústria, mobilizando os diferentes atores num sentido único. As instâncias do governo passam a assumir uma atitude facilitadora das dinâmicas interrelacionais entre as esferas, promovendo e participando em parcerias de interesse social, mas, essencialmente, com o reconhecimento (promovendo aceitação pública) de que o desenvolvimento tecnológico e industrial constitui a base do desenvolvimento sustentável. Nesse cenário, a indústria tem cada vez mais noção de que sua competitividade depende da constante inovação e adequação às exigências do mercado. Entretanto, a maior parte das empresas não dispõe de capital para assumir projetos de pesquisa aplicada e desenvolvimento experimental. Neste sentido, essas empresas buscam projetos de parceria com as universidades. A entrada da fase 3 é marcada pelo momento em que os atores do processo de inovação tomam consciência de que “[...] as organizações são entretecidas, as suas fronteiras definidas e alteradas, e as suas interrelações concretizadas não apenas como relações entrada-saída, mas como interdependências não negociáveis, sujeitas a um elevado grau de reflexividade” (STORPER, 1997). FASE 3: O modelo da hélice tripla

Figura 2.4 - Fase 3 do modelo hélice tripla

Fonte: ETZKOWITZ; LEYDESDORFF, 2000 (Reproduzido com autorização)

O reconhecimento das alterações ocorridas na fase 2, e as implicações da reorganização institucional e interrelacional entre as diferentes esferas, implicam na reestruturação das esferas, a um passo que levam a assumir o papel umas das outras, diluindo as fronteiras entre as instituições no centro da dinâmica helicoidal formada pelas três esferas (Figura 2.4). A diluição das fronteiras institucionais não corresponde a uma perda de identidade dos atores do processo de inovação, mas resulta na atribuição de uma missão comum a todas as esferas: A “capitalização do conhecimento” (ETZKOWITZ, 2008). A indústria assume a “capitalização do conhecimento” como a forma de se manter competitiva. A universidade passa a assumi-la não apenas como uma forma de obter financiamento externo, mas como uma função social, adotando um papel de agente com poder para se tornar o motor do desenvolvimento social, através de sua capacidade em transferir conhecimento. Desta forma, a universidade torna-se um agente econômico direto, e a produção de conhecimento um empreendimento de facto. Nesta nova filosofia, instituições governamentais agem como parceiros com igual poder, agindo como financiadores, mas também como sócios com poder de decisão e orientação do processo de inovação, encarando a “capitalização do conhecimento” como um mecanismo para alavancar o desenvolvimento.

O sistema de inovação na fase 3 do modelo da hélice tripla apresenta cinco características particulares (ETZKOWITZ, 2008) que o distingue dos sistemas nas fases 1 e 2, a saber: 1. A “capitalização do conhecimento” torna-se a base para o desenvolvimento econômico e social, pela qual a universidade, enquanto entidade empreendedora, adota um papel central nos processos de transferência de tecnologia e na “economia do conhecimento”. 2. As três hélices do modelo, universidade, indústria e governo, são autônomas e independentes. 3. A densa rede de relações entre as três esferas do modelo e a formação das relações institucionais, resulta num grau de interdependência elevado. De forma que, o posicionamento de cada uma das esferas determina e é determinado pelo posicionamento das outras esferas no processo de inovação. 4. A resolução das tensões entre independência institucional e interdependência organizacional dá origem a novas formas de organização funcional e instituições híbridas (incubadoras, institutos de pesquisas, etc.), potencializando e agilizando os processos de transferência tecnológica. 5. A alteração dos modelos relacionais entre as três hélices dá origem a ajustes estruturais contínuos em cada uma delas, o que, por sua vez, promove a renovação dos modelos relacionais e novas formas de interação. A “capitalização do conhecimento”, que permite a cada uma das esferas atingir objetivos próprios, constitui o fator de aproximação delas, originando um “espaço” central de cooperação e discussão voluntárias, onde ocorre a partilha de informações mútuas (AUXILIAR, 2010).

2.2.2 O papel das instituições

Nos processos de desenvolvimento com base em dinâmicas do tipo hélice tripla, pode-se constatar que o papel de cada um dos atores no processo de

29 transferência tecnológica e de conhecimento, se vai alterando à medida que o processo passa por suas diferentes fases Na fase 1, identifica-se uma universidade pouco envolvida no processo de transferência tecnológica. A universidade como “Torre de Marfim” produz ciência e sua relação com a indústria ocorre fundamentalmente pelo ensino, não tendo papel ativo na inovação. A inovação pertence, e está contida, à esfera da indústria, que desenvolve novos produtos, aplicações e processos. O governo, por sua vez, determina o enquadramento de todo o processo, porém, embora controle-o, não participa ativamente no processo. Na fase 2, a universidade participa mais ativamente do processo de inovação, partilhando com a indústria as funções de pesquisa aplica e desenvolvimento experimental. Nesta fase, o governo assume uma postura de menor controle, no entanto aproxima-se mais das outras duas esferas, como facilitador das relações entre estas. Já a indústria adere mais facilmente a laboratórios e equipamentos para desenvolver seus projetos de investigação e pesquisa, inicialmente com a aquisição de serviços e parcerias com as universidades. Na fase 3, as três hélices encontram-se entrelaçadas numa espiral, em que o posicionamento de cada uma influencia o, e é influenciado pelo, posicionamento das outras. As três esferas institucionais participam como parceiras na transferência de tecnologias e conhecimentos, alterando e alternando-se em suas funções, diluindo as fronteiras institucionais e criando instituições híbridas. A iteratividade e interdependência entre os atores corroboram para a necessidade de gestão das interfaces entre produtores, intermediários e usuários de inovação, fruto da conscientização crescente que demanda articulação permanente pelo provimento de estratégias e pontes entre os atores e grupos de interesse com diferentes anseios sociais e posições institucionais. Nesta conjectura, Farinha e Ferreira (2013) propuseram o modelo da triangulação da hélice tripla, apresentado na figura 2.5, onde a inovação e o empreendedorismo são vistos como catalisadores do desenvolvimento e como mediadores da competitividade empresarial com base na gestão em rede e enraizada nos três pilares da sustentabilidade: ambiental, econômico e social.

Figura 2.5 - Modelo de triangulação da hélice tripla

Fonte: FARINHA et al., 2016 (Reproduzido com autorização)

A análise das motivações e dos elementos que influenciam e catalisam o processo auxilia no entendimento das condições que regem e criam o sistema de inovação. Do ponto de vista das regras, normas e relações, as ações são sempre de fundo político, definidas com base nos valores e paradigmas vigentes nas distintas instâncias do sistema.

A propagação da inovação se dá por adoção e troca de informações entre agentes, num processo associado à teoria de percolação social (FRENKEN, 2006). Deste modo, a inovação é compreendida como processo coletivo, socialmente construído e passível de transformações a partir de novas leituras/percepções da realidade e apropriações tecnológicas. Assim, não é o mercado que cria a oportunidade de inovação; são os usuários que traçam estas oportunidades (SMITS; KUHLMANN, 2004). Neste esteio desenvolve-se o conceito de inovação sustentável, na qual a inovação é direcionada ao bem estar das população, que respeita princípios éticos, adapta-se ao usuários, sendo consistente ao seu modo de vida, é transparente, ecológica e inclusiva (DEARING, 2000), fruto de uma trajetória de evolução da racionalidade instrumental para a racionalidade substantiva (DUDZIAK, 2007). A universidade, no contexto da plena integração entre as instituições, não vende inovação, mas produz conhecimento que potencialmente pode traduzir-se em inovação na indústria. Assim, o empreendedorismo acadêmico é, por um lado a extensão das atividades de ensino e pesquisa, e por outro lado, um processo de internalização da atividade de transferência tecnológica e de conhecimento. De acordo com Auxiliar (2010), a universidade empreendedora assenta-se em quatro pilares fundamentais: 1. Liderança acadêmica com capacidade de formular e implementar uma visão estratégia. 2. Autonomia patrimonial, administrativa e financeira. A universidade detém o controle legal dos recursos acadêmicos, incluindo a propriedade física e intelectual resultante da pesquisa acadêmica, e tem a capacidade para proceder a decisões e atos administrativos definitivos, com celeridade e flexibilidade adequadas a situações específicas. 3. Capacidade organizacional para transferir tecnologia através de patenteamento, licenciamento e incubação. A existência de estruturas acadêmicas dedicadas, com competências para procurar, promover e comercializar competências, projetos e resultados de pesquisas e investigações entre a universidade e o setor empresarial

4. Uma cultura empreendedora entre administradores, acadêmicos e estudantes. Sendo a universidade incubadora de iniciativas empresariais e viveiro de novos ramos científicos e de novos setores industriais, a universidade empreendedora toma a iniciativa neste processo, tornando-se fonte de tecnologia, da mesma forma que o é de recursos humanos e conhecimentos, utilizando suas competências de investigação e ensino, em áreas avançadas de ciência e tecnologia, para a promoção de inovação.

2.3 O QUE É ENGENHARIA?

Segundo a enciclopédia britânica, engenharia é a aplicação da ciência para a conversão ótima dos recursos naturais para os usos da humanidade (ENCYCLOPÆDIA BRITANNICA, 2018). Já a Academia Real de Engenharia (ROYAL ACADEMY OF ENGINEERING, 2018) propõe uma definição igualmente extensional, porém tão abrangente que praticamente engloba toda atividade humana. É Callaos (2018), em seu trabalho intitulado The Essence of Engineering and Meta-Engineering: A Work in Progress, quem dá o primeiro passo para uma definição intensional da engenharia – exposta aqui e base para a contextualização da engenharia no processo ARES –, estruturando suas características necessárias e suficientes, comuns em suas diferentes disciplinas e contextos. Utilidade: O ato de produzir coisas úteis ou gerar benefícios para a humanidade é condição necessária (porém não suficiente) para a atividade de engenharia. Know-how e know-that (Techné e Scientia): O conceito geral de aprendizagem através da experiência remonta ao berço da filosofia ocidental. Aristóteles em sua ética a Nicômaco escreveu que “as coisas que temos que aprender antes de podermos fazê-las, aprendemos fazendo-as” (ARISTÓTELES, 1999). O filósofo da língua inglesa, Ryle, categoriza esse aprendizado como know-how – saber fazer ou conhecimento técnico, techné – diferenciando este do que ele chamou de know-that – saber fatos, scientia. Know-that e know-how estão intimamente interligados na

33 engenharia, de fato é impossível desenvolver um software, por exemplo, que certamente precisa de know-how, sem conhecer as regras da linguagem de programação escolhida e os requisitos a serem atendidos pelo software, bem como suas entradas e saídas, que são instâncias do know-that. Para Callaos (2018), know-how, enquanto conhecimento metodológico e processual/procedimental, faz parte da essência da engenharia e, como tal, é condição necessária nas atividades de engenharia, mas não suficiente para defini-la unicamente. Scientia e techné são duas dimensões diferentes da engenharia. Conhecimento tácito: Uma vez que a engenharia, principalmente em sua fase de design, é uma atividade extremamente criativa (MALPAS, 2000), a intuição (conhecimento tácito, não-proposicional) é ingrediente – e condição necessárias – de muitas de suas práticas. O conhecimento tácito (POLANYI, 1962) está intrinsicamente embutido nas atividades da engenharia; representações visuais, como imagens e diagramas, ajudam a expor o conhecimento tácito, incorporado à experiência como conhecimento pessoal e resultante da prática individual. Prática e praxis: Sendo o conhecimento tácito/pessoal e o know-how/techné condições necessárias nas atividades da engenharia, torna-se evidente que a prática/praxis também é condição necessária para a engenharia; tanto para adquirir novos conhecimentos tácitos e apoiar o know-how e o conhecimento de processo, quanto para gerar techné, a fim de produzir a coisa técnica ou artificial, i.e., artefatos. Das propriedades acima descritas, define-se engenharia como “o desenvolvimento de novos conhecimentos (scientia), novas “coisas feitas” (techné) e/ou novas formas de trabalhar e fazer (praxis) com o propósito de criar novos produtos úteis (artefatos) ou serviços” (CALLAOS, 2018). Scientia, techné e praxis, figura 2.6, são três dimensões imprescindíveis para a concepção da engenharia como um todo (ocupação e/ou profissão).

Figura 2.6 - Relação entre engenharia, scientia, techné e praxis

Fonte: CALLAOS, 2018

A engenharia como scientia, ou mais especificamente como scientia ingenieriae, é desenvolvida principalmente na academia; como techné é praticada principalmente na indústria gerando inovações tecnológicas; e como praxis é realizada tanto em organizações técnicas quanto não-técnicas, apoiando atividades gerenciais e procedimentos técnicos, por meio de design e implementação metódico e metodológico.

2.3.1.1 Engenharia, ciência e indústria

As interrelações entre engenharia, ciência e indústria, sumarizadas na figura 2.7, ocorrem em ciclos de feedback baseados na combinação dos diferentes tipos de conhecimentos envolvidos na atividade de engenharia, e em ciclos de feedback mediados pela criação de valor, tendo a engenharia como elemento de ligação, ou uma ponte, entre a academia (representada pela ciência) e a indústria.

Figura 2.7 - Interação entre engenharia, ciência e organizações industriais e empresariais

Fonte: CALLAOS, 2018

Engenharia e ciência: O conhecimento científico é um conhecimento sobre fatos (know-that), descritivo/declarativo e proposicional, apoiado em lógica. A engenharia é nutrida por esse tipo de conhecimento, mas também precisa do conhecimento prescritivo, procedimental e não-proposicional. Destarte, as relações dialéticas geradas entre ciência e engenharia removem qualquer relação hierárquica entre elas; não a ciência nem superior nem inferior à engenharia. As atividades científicas e de engenharia estão relacionadas umas às outras e integradas num todo mais abrangente (figura 2.7), no qual a ciência fornece o conhecimento proposicional que as atividades e pensamentos de engenharia precisam como um de suas entradas; e os processos e tecnologias produzidos pela engenharia apoiam as atividades científicas e proporcionam um processo científico racional e uma possível base para reflexões filosóficas. De acordo com essa perspectiva, Callaos (2018) advoga que as atividades científicas e de engenharia podem ser relacionadas, tal qual apresentado na figura 2.8, por meio de feedback e de feedforward, a fim de gerar sinergias mútuas em que o todo seria maior que a soma de suas partes.

Figura 2.8 - Relação engenharia/ciência

Fonte: CALLAOS, 2018

Engenharia e indústria: Os produtos de engenharia, para tornassem realmente utilizados (coisa útil em uso) e, assim exercer seus impactos sobre a criação de valor/riqueza e trazer benefícios para a humanidade, requerem a processos industriais e empresariais/comerciais. Os processos de engenharia interagem com os processos industriais e empresariais a fim de transformar o conhecimento de engenharia, apoiado em suas três dimensões (scientia, technê e praxis), em inovações tecnológicas e bens e serviços. Cabe ressaltar que a relação entre as organizações industriais e empresariais e a engenharia, esquematizada na figura 2.9, ocorrem por meios complementares e sinérgicos similares aos das relações entre ciência e engenharia – por feedback positivo e feedforward.

Figura 2.9 - Relação engenharia/organizações industriais e empresariais

Fonte: CALLAOS, 2018

3 PROBLEMATIZAÇÃO

A pesquisa aplicada, em sua realização prática da ciência, acessa parte dos conhecimentos, métodos, técnicas e tecnologias acumulados no acervo da academia com uma finalidade específica, que anseia a inovação. Intuitivamente, pode-se pensar que a pesquisa aplicada advém diretamente da pesquisa básica, e que prossegue para a invenção, e desta para a inovação. Entretanto, a progressão da pesquisa parece abranger várias etapas intermediárias e o desenvolvimento de elementos de múltiplas tecnologias, que se combinam no produto da invenção e inovação, retratando a complexidade desordenada do “mundo real” em seu entorno. Em seu intento, os agentes de inovação e motores da pesquisa aplicada – universidades e instituições científicas e tecnológicas (ICTs) – empenham-se na busca e no uso de metodologias que tragam transparência e solidez ao processo de inovação (CELEST et al., 2014). Segundo Dudziak (2007, p. 48), “a tecnologia, sendo produtora e produto do processo de inovação, reflete o grau de conhecimento acumulado, o conjunto de competências e a capacidade de aprendizado que uma organização mobiliza em um dado momento. A capacidade tecnológica seria aumentada a partir do aprendizado contínuo, que alimentaria as competências essenciais e as capacidades dinâmicas”. Partindo desta perspectiva e sob a ótica da pesquisa aplicada de engenharia, define-se inovação como um processo de transformação resultante das competências e das tecnologias acumuladas, obtidas a partir do conhecimento tácito e explícito acumulados como resultado do aprendizado e da pesquisa continuada. Sob a luz da prospecção, internalização, apropriação, transformação e transferência do conhecimento, preposto da pesquisa continuada e atributo da capacidade motriz de inovação a uma organização, e da busca por solidez e transparência nos procedimentos e métodos aplicados ao empreendimento de inovação, conduziu-se uma investigação de um cânone de metodologias da engenharia de sistemas. Uma busca por um caminho, dentro do ambiente da pesquisa aplicada de engenharia, para a inovação.

3.1 ANÁLISE E INVESTIGAÇÃO

Da miríade de processos, metodologias e meta-processos investigados, algumas características desfavoráveis, contraproducentes à pesquisa continuada e a inovação, parecem permear grande parte do universo de metodologias. Dessas características, destacam-se: • A forte ligação com um conjunto específico de ferramentas e/ou linguagens que, num mecanismo similar ao relativismo linguístico (WHORF, 1980), limita a criação de artefatos e de conhecimento, visto ser necessário o domínio da sintaxe, semântica e pragmatismo da ferramenta e/ou linguagem específica para que hajam efetivas contribuições dos participantes e membros da pesquisa. • O vínculo patente com a disciplina da engenharia de software que, principalmente naquelas ditas ágeis, parece desassistir as demais disciplinas da engenharia. • A ausência de um mecanismo explícito sobre a prospecção, internalização, apropriação, transformação e transferência do conhecimento que fere o princípio basilar de uma pesquisa continuada. Entretanto, dos objetos estudados, uma metodologia, um framework e um processo se destacam dos demais por apresentarem qualidades únicas que prefiguram trilhar o caminho da inovação no contexto da pesquisa aplicada de engenharia, a saber: Object-Oriented Systems Engineering Method (OOSEM), Rational Unified Process for System Engineering (RUP SE), Feature-Driven Development (FDD).

3.1.1 Object-Oriented Systems Method (OOSEM)

A metodologia OOSEM (ESTEFAN et al., 2008) fornece um framework integrado que combina técnicas de orientação a objetos (OO), uma abordagem de design baseada em modelos e práticas tradicionais top-down de engenharia de sistemas. Originalmente fundamentado na modelagem UML® (Object Management

Group Unified Modeling Language ™), a OOSEM foi realinhada com a linguagem SysML® (Object Management Group System Modeling Language ™) em 2006 e é atualmente recomendada como um exemplo de boas práticas e o paragone das metodologias baseadas em modelos. A descrição detalhada da OOSEM é fornecida pela INCOSE em seu Systems Engineering Handbook (INCOSE, 2015). Os objetivos dessa metodologia são: • Capturar informações em todo o ciclo de vida suficientes para especificar, analisar, projetar, verificar e validar o sistema. • Integrar a engenharia de sistema baseada em modelos (Model-Based System Engineering – MBSE) com métodos OO de software, hardware, e de outras disciplinas da engenharia. • Suportar a reutilização a nível de sistema e a evolução/mutação do design. As fases e atividades definidas na OOSEM, apresentadas na figura 3.1, são praticadas sobre um ciclo de vida “Vee” recursivo e aplicadas iterativamente em cada nível de hierarquia do sistema.

Figura 3.1 - Fases e atividades da metodologia OOSEM

Fonte: ESTEFAN, 2008 (Reproduzido com autorização)

Análise das necessidades das partes interessadas: Neste primeiro grupo de atividades, os requisitos (necessidades/desejos) das partes interessadas (stakeholders) para o sistema são reunidos e analisados usando-se de uma abordagem de design “orientado para o uso” (usage-driven); definindo interações do usuário com o sistema e elaborando casos de uso (use-cases) em cenários operacionais definidos na terminologia nativa do usuário final. Esta atividade captura as características do sistema atual (se existir) em termos das partes interessadas, do contexto do negócio, do uso e do design. Esta análise ajuda a identificar os candidatos à reutilização (do sistema atual ‘as-is’ ao sistema proposto ‘to-be’), documentar procedimentos e doutrinas operacionais relevantes, e revelar aspectos do sistema atual que podem ser melhorados. Definição dos requisitos do sistema: O método de “orientação ao uso”, empregado na análise das necessidades das partes interessadas, gera casos de uso e diagramas de cenários que descrevem o comportamento pretendido do sistema. Os requisitos do sistema são então modelados e definidos dessa maneira, começando com a definição do sistema como uma “caixa-preta” que interage com outros sistemas e com os usuários. A partir dessas interações e cenários, é possível consolidar um conjunto mínimo de funções de alto nível para o sistema. Essas funções constituem o ponto de partida para a arquitetura e design. Definição da arquitetura lógica: Esta atividade consiste em decompor e particionar o sistema em componentes lógicos, que capturam as funcionalidades do sistema, que interagem para satisfazer seus requisitos. Os cenários lógicos preservam as interações do sistema em “caixa preta” com o ambiente. Além disso, as funcionalidades dos componentes lógicos são re-particionadas com base em critérios tais como coesão, acoplamento, confiabilidade e desempenho. Síntese da arquitetura alocada: Na metodologia OOSEM, as arquiteturas físicas candidatas são constituídas por nós, que representam a agregação de componentes físicos em um local específico. Os componentes lógicos do sistema são então alocados nesses nós físicos. Esses nós físicos são tipicamente definidos em termos de hardware, software, dados ou componentes de procedimento manual.

A forma como os nós estão conectados pode ser baseada em designs existentes ou arquiteturas de referência. Otimização e avaliação de alternativas: Esta atividade é invocada em todas as demais fases e atividades da metodologia OOSEM para otimizar as arquiteturas candidatas e realizar estudos de mercado para selecionar arquiteturas. Modelos paramétricos para modelagem de desempenho, confiabilidade, disponibilidade e outras preocupações da engenharia especializada são utilizados na análise, comparação e otimização das arquiteturas candidatas. Verificação e validação do sistema: Esta atividade destina-se a verificar se o design do sistema satisfaz os requisitos e validar se os requisitos atendem às necessidades e desejos das partes interessadas. Planos, procedimentos e métodos de verificação, a exemplo da inspeção, demonstração e testes, são desenvolvidos. Casos de uso, cenários e requisitos associados em nível de sistemas são as entradas primárias para o desenvolvimento de casos de teste e de procedimentos de verificação. Durante esta atividade, os requisitos do sistema e informações de design são rastreados para os métodos de verificação do sistema, casos de teste e resultados.

3.1.1.1 Análise e características da metodologia OOSEM

Tão universais quanto os conceitos de OO empregados na OOSEM podem ser, quando combinados e aplicados em sistemas complexos, ou em sistema-de- sistemas, apresentam uma curva de aprendizado significativa para aqueles que não estão familiarizados com a terminologia e abstrações da engenharia de software. Mesmo que haja um paralelo imediato nas mais diversas disciplinas da engenharia para conceitos como herança e instanciação, isso não implica dizer que um pesquisador ou engenheiro conseguirá enxergar ou mesmo fazer uso de uma abstração OO. Em certo sentido, um objeto na percepção e cognição humana é apenas uma maneira de ver o mundo dentre muitas possíveis, e a “orientação a objetos” impede o uso de múltiplas visões sobre o problema ou o uso de transformações lógicas ou funcionais.

Um modelo OO é a decomposição do domínio do problema em classes ou interfaces e relações, de modo que a capacidade para suportar visões múltiplas exigiria a capacidade de alterar/trocar facilmente entre diferentes decomposições de classes e relações, o que violaria o encapsulamento. Se o conceito de concorrência for adicionado a este contexto, o aporte de múltiplas visões numa modelagem OO se tornaria ainda mais complicada e contra intuitiva. Outro aparente problema da abordagem OO da metodologia OOSEM, reside na definição dos requisitos ditos não-funcionais, a exemplo dos requisitos de desempenho, confiabilidade, segurança, disponibilidade, etc. Nesta abordagem, os requisitos não-funcionais se apresentam geralmente de maneira incompleta ou vaga sobre as condições de operação contra as quais precisam ser alcançadas. Esta ambiguidade muitas vezes leva o designer a fazer suposições sobre as condições implícitas em um requisito, o que pode levar a uma solução que não executa a operação da maneira pretendida. Na definição dos requisitos do sistema, a metodologia utiliza uma aproximação bastante didática e intuitiva. Definindo-se um sistema como uma “caixa-preta” primeiro, pode-se descrevê-lo em termos de suas interações com o ambiente e com entidades externas (através de diagramas de contexto, casos de uso e cenários); a ênfase é colocada na identificação e definição de interfaces, propriedades e uso do sistema num contexto mais amplo, delimitando o problema que se quer resolver, sem prefixar uma solução particular. Desenvolver e visualizar um design em diferentes níveis de abstração pode ajudar a lidar e gerenciar a complexidade do sistema. Sendo assim, uma abstração é usada com o propósito de revelar apenas informações e propriedades do sistema pertinentes para um determinado nível, escondendo detalhes de baixo nível irrelevantes para o propósito da abstração. Mesmo que não explicitamente, a metodologia OOSEM traz a análise das necessidades das partes interessadas, capturadas como declarações e diagramas de alto nível, como a representação mais abstrata do sistema. O que faz da arquitetura física, detalhada em esquemáticos e artefatos de engenharia, a representação de menor abstração para um sistema. No entremeio destas abstrações, a OOSEM aporta uma arquitetura

46 funcional, composta por descrições independentes de solução, e uma arquitetura lógica, que descreve soluções em termos de componentes lógicos. Estes componentes representam as tecnologias e a implementação da abstração independente de componentes físicos, restando a arquitetura física definir uma implementação específica para o design correspondente a uma arquitetura lógica particular.

3.1.2 Rational Unified Process for System Engineering (RUP SE)

O framework RUP® oferece uma estrutura para racionalizar as atividades relacionadas ao ciclo de vida de desenvolvimento de software. Desde sua estreia formal em 1996, o RUP® sofreu, e vem sofrendo, mudanças para suportar uma variedade de requisitos de desenvolvimento, incluindo a disciplina de engenharia de sistemas. Neste sentido, o plug-in RUP SE® (CANTOR, 2003), criado em 2001, foi desenvolvido para abordar os problemas e requisitos relacionados ao design de sistemas dentro do ambiente RUP. O objetivo do RUP SE é dar suporte às equipes de engenharia de sistemas na medida em que elas determinam e delimitam o sistema em “caixa-preta” e especificam um design do sistema em “caixa-branca” (e.g., estrutura interna do sistema, seus elementos, componentes e partes) que atende os requisitos das partes interessadas. Em particular, o RUP SE abrange: • Um framework de arquitetura, que descreve os elementos internos de um sistema (elementos de arquitetura) de vários pontos de vista; • Um conjunto de artefatos baseados em UML e/ou SysML para modelagem da arquitetura do sistema; e • Uma metodologia, denominada use-case flowdown, que deriva e desdobra requisitos para elementos de design e arquitetura. O framework RUP SE para a arquitetura do sistema é implantado em duas dimensões distintas, nível de modelo e ponto de vista (BALMELLI et al., 2006), relacionadas no quadro 3.1.

Quadro 3.1 - Dimensões do framework RUP SE

Fonte: BALMELLI et al., 2006

Nível de modelo Um nível de modelo é definido como um subconjunto do modelo de arquitetura que representa certo nível de especificidade; níveis mais baixos apresentam mais especificidade e capturam escolhas tecnológicas. Níveis de modelo são elementos projetados para agrupar artefatos com níveis similares de detalhes e abstração. O nível de contexto considera todo o sistema como uma única entidade, um sistema “caixa-preta”, endereçando as interações do sistema com entidades externas e com o meio. No nível de análise, os elementos internos do sistema são identificados e descritos num nível de abstração relativamente alta (sistema em “caixa-branca”). A construção desses elementos varia, dependendo do ponto de vista específico. Por exemplo, no ponto de vista lógico, subsistemas são criados para representar elementos de funcionalidades numa abstração de alto nível. No nível de design, as decisões que direcionarão a implementação são capturadas. Na transição entre o nível de análise e o nível de design, subsistemas, classes, e a distribuição dos recursos físicos (localities) são transformados em hardware, software, etc. Cabe notar que a transição entre os níveis de análise e design não se trata de um mapeamento direto dos elementos do sistema para design; representa, em contrapartida, decisões de design, balizadas por requisitos derivados e escolhas de distribuição, representadas pelas localidades (localities) e suas características. Ou seja, é no nível que análise que a arquitetura do sistema é definida e especificada, criando requisitos que o nível de design deve satisfazer. No nível de implementação, as decisões sobre escolhas técnicas e tecnológicas para a implementação são capturadas. Como antes, a transição entre os níveis de design e implementação é uma transformação. Porém, diferente das transformações anteriores, onde a transição entre níveis geralmente acarreta na decomposição dos componentes dos modelos, neste nível o mapeamento é mais direto, onde, no geral, um componente de design é transformado em um componente de implementação. Ponto de vista

Um ponto de vista é definido como um subconjunto do modelo de arquitetura que endereça e aborda um conjunto de interesses e preocupações da engenharia. Os pontos de vista permitem que os usuários do framework abordem separadamente e independentemente diferentes questões de engenharia, mantendo uma representação integrada e consistente do design. Os pontos de vista escolhidos no RUP SE foram derivados do modelo de referência para processamento distribuído aberto, RM-ODP (Reference Model for Open Distributed Processing), e teve sua documentação fortemente influenciada pela norma ANSI/IEEE 1471:2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, substituída pela ISO/IEC/IEEE 42010:2011. O ponto de vista do trabalhador expressa os papéis e responsabilidades dos operários, trabalhadores e operadores do sistema quanto à entrega dos serviços do sistema; e, em consequência de serem parcialmente responsáveis pela entrega dos serviços e funcionalidades do sistema, são parte integrante do sistema. Os trabalhadores são tanto entidades lógicas quanto físicas. São entidades lógicas na medida que podem, quando instruídos, prestar serviços e colaborar com outras entidades lógicas. E são entidades físicas posto que são limitados em termos de desempenho, reatividade e capacidade. O ponto de vista lógico diz respeito à decomposição lógica do sistema em um conjunto coerente de subsistemas que colaboram para fornecer o comportamento desejado. Os elementos das visualizações no ponto de vista lógico são classes e subsistemas – pacotes e classificadores – UML. O ponto de vista físico ou ponto de vista de distribuição considera a decomposição física do sistema e a especificação de componentes físicos. Os diagramas de localidade são a expressão mais abstrata desta decomposição. Eles expressam onde um processamento ocorre sem amarrar a localidade de processamento a uma localização geográfica específica, ou mesmo a realização do processamento a um hardware específico. Neste contexto, localidade refere-se à proximidade de recursos, não necessariamente localização, a exemplo da distribuição de processamento num contexto de sistema-de-sistemas. Esses

50 diagramas, tal como representados no framework RUP SE, consistem de dois elementos: localidade e conexão. Uma localidade é um agrupamento de recursos físicos que permitem uma partição conceitual e física do sistema. Semanticamente, as localidades são usadas para realizar as características físicas da classe do sistema. Em particular, as localidades possuem atributos de classe e instância e medidas de eficácia associadas capturadas como valores. Conexão, por sua vez, representa o vínculo entre as localidades que podem ser usadas para passar dados, solicitações de serviço ou entidades do tipo entrada e saída. As conexões são estereótipos de associações com marcações de valores, que capturam as características únicas da conexão, como a taxa de transferência ou protocolos suportados pela conexão específica. O ponto de vista da informação concentra-se nas informações armazenadas e processadas pelo sistema. O uso da UML para modelagem de banco de dados relacional e objetos é prática consolidada pela engenharia de software que o RUP SE faz uso no ponto de vista da informação, apoiando associações entre dados e classes funcionais, e atribuindo componentes do bando de dados a localidades. No ponto de vista do processo, os segmentos de controle que realizam os elementos computacionais são examinados e as questões de concorrência, confiabilidade e particionamento do processamento são endereçadas. Por fim, o ponto de vista geométrico indica a relação espacial entre os componentes físicos, preocupando-se com a capacidade de fabricação e acessibilidade. Visualizações No framework RUP SE, as intersecções entre os pontos de vista e os níveis de modelo são chamadas visualizações. Visualizações englobam artefatos que descrevem como os interesses e premissas de engenharia de um determinado ponto de vista é endereçado num nível de modelo particular. Em RUP, um conjunto específico de visualizações que compõem e atendem as necessidades de um projeto define o caso de desenvolvimento (development case), que inclui os

51 artefatos e políticas de documentação, associadas a diretrizes, padrões (templates) e checklists.

3.1.2.1 Metodologia use-case flowdown

Use-case flowdown (CANTOR, 2003) é a metodologia adotada no framework RUP SE para realizar a transição entre os níveis de modelo. Esta metodologia engloba atividades para derivar e desdobrar requisitos funcionais para sistemas e seus elementos, podendo ser aplicada para adicionar detalhes dentro de um nível de modelo ou para especificar elementos num nível de modelo de maior granularidade. Por exemplo, a use-case flowdown pode ser usada tanto para determinar os serviços do sistema no nível de contexto, quanto para identificar subsistemas, ou mesmo para quebrar subsistemas em outros subsistemas, no nível de análise. Através do emprego recursivo dessa metodologia os requisitos são desdobrados e propagados entre os níveis de modelo, partindo do contexto para a análise e da análise para o design. Esta abordagem consiste em considerar os elementos “caixa-branca” como elementos “caixa-preta” na próxima aplicação na recursão. Isso permite que apenas o nível apropriado de especificidade seja analisado e discutido, possibilitando a adição de detalhes ao sistema num nível consistente de abstração. Outra característica da aplicação recursiva da metodologia use-case flowdown, é viabilizar designs concorrentes, de forma que, cada elemento “caixa-preta” pode ser tratado por equipes ou estratégias diferentes, criando conjuntos distintos de designs possíveis. As etapas dessa metodologia devem ser aplicadas como uma realização conjunta (joint realization): analisando como os elementos de múltiplos pontos de vista e visualizações colaboram na entrega de um serviço, determinando simultaneamente a colaboração e correlação entre elementos lógicos, físicos e de informação. O procedimento para a realização conjunta consiste de: 1. Escolher os pontos de vista participantes, sendo o ponto de vista lógico obrigatório.

2. Para cada “caixa-branca” na realização de um serviço em “caixa-preta”, deve-se: a. Especificar o elemento lógico que a executa; b. Modelar como os pontos de vista adicionais participam. Neste processo, caso um elemento lógico em “caixa-branca” requeira mais de um elemento dos outros pontos de vista, deve-se dividir este ciclo (recursão) em etapas, de forma que cada etapa requeira exatamente um elemento “caixa-branca” de cada ponto de vista. c. Criar diagramas de interação para cada ponto de vista; 3. Derivar os requisitos suplementares de desempenho, precisão, e assim por diante, para cada etapa; avaliar/confirmar com os diagramas de interação.

3.1.2.2 Análise e características do framework RUP SE

Reside na ideia de transição entre os níveis de modelo, alicerçada no framework, a suposição da suficiência e da plena aplicação da modelagem como veículo de transformação e refinamento. Entretanto, tal aplicação nem sempre é factível ou factual. Quando sob a ótica do trabalhador, a transição entre os níveis de design e implementação parece de difícil compreensão ou impraticável. Supondo, por exemplo, que as atividades funcionais de um trabalhador (ou corpo de trabalho) foram mapeadas para uma especificação de posição (cargo) com um conjunto bem definido de habilidades e responsabilidade, a proposta do framework RUP SE, no nível de implementação, considera que as especificações do trabalhador podem ser cumpridas contratando-se alguém com as habilidades e competências especificadas, similar a escolha de um componente eletrônico de prateleira, ou, alternativamente, podem ser cumpridas treinando um membro de seu corpo de trabalho para adquirir as habilidades necessárias, assemelhando-se a fazer uma implementação interna de um componente de software. Porém, não há mecanismo explícito ou implícito, tampouco semântica aplicável, que realize essa proposta de transformação das atividades a serem desempenhadas por um

53 trabalhador em um conjunto específico de habilidades e competências que o mesmo deva possuir. Na decomposição lógica do sistema em subsistemas, o framework esbarra no reducionismo sintático da linguagem UML. Não existe uma sintaxe UML que capture os aspectos classificador e do pacote de um subsistema, sendo os subsistemas normalmente representados como pacotes com dependências. Na tentativa de trespassar a barreira UML, o RUP SE se apropria de estereótipos de classes proxy, usados para representar o componente semântico classificador, e de estereótipos de pacote para definir sistemas e subsistemas e adicionar semântica a composição. No entanto, esta estratégia não supera a barreira OO, defrontando- se com as mesmas limitações que esta abordagem inflige sobre a metodologia OOSEM, limitante da construção de múltiplas apreciações sobre a decomposição lógica do sistema. A imposição da sintaxe e semântica UML/SysML no framework RUP SE traz ainda outras restrições e insuficiências que requerem um vasto domínio da linguagem e de seu emprego para a adequada representação de sistemas complexos. No RUP SE um nó é um tipo especial de localidade que é usado nos níveis de modelo de design e de implementação para especificar recursos físicos que executam softwares. No entanto, como um tipo de localidade, os nós podem ser estereotipados para incluir toda a semântica da localidade específica – semântica esta que difere da definição de nó em UML (RUMBAUGH et al., 2005). Sendo assim, localidades não são mais estereótipos dos nós do que os nós são estereótipos das localidades. Ademais, a linguagem permite a organização das operações e, portanto, dos serviços do subsistema, em interfaces. Logo, entende- se uma interface como um subconjunto de serviços de um subsistema. Isto posto, em UML, e consequentemente no RUP SE, os serviços dos subsistemas são agrupados (previamente) e define-se as interfaces necessárias para cada um destes grupos (posteriormente definidas), para só então atribuir cada interface à localidade apropriada; um trajeto tortuoso e contra intuitivo para qualquer outra disciplina de engenharia que não a engenharia de software.

Na qualidade de uma linguagem sobre a abordagem OO, a UML, como aplicada no RUP SE, insere ainda mais dubiedade sobre o conceito de localidade. Tal qual os subsistemas, as localidades podem ser decompostas hierarquicamente em outras localidades. Entretanto é dúbia a associação entre as partes e o todo. No uso geral da linguagem (UML), se considerada a agregação, relação associativa que expressa o conceito “é parte de”, quando um objeto de classe (todo) agrega outros objetos de classe (partes), os atributos do todo incluem os atributos das partes. Os atributos do todo numa localidade de sistema são funções dos atributos das partes (sublocalidades), mas não há semântica em UML que expresse tais relações funcionais entre atributos, e mesmo aquelas expressas em SysML não compreendem a totalidade das relações possíveis, tornando difícil manter a rastreabilidade dos requisitos derivados entre localidades e seus componentes, trazendo ainda mais impedimentos para a plena comunicação e discussão das decisões tomadas ao longo do desenvolvimento. Na metodologia use-case flowdown, adotada no framework RUP SE, propõe- se a construção de um diagrama de contexto para cada subsistema UML/SysML mostrando os atores do sistema com os quais o subsistema colabora, bem como os subsistemas com os quais compartilha alguma relação de dependência. Do ponto de vista do subsistema, a realização do serviço é, então, a forma como este colabora com os atores no desempenho de seus papéis. Nesta perspectiva, a metodologia muda o foco da heurística da análise de casos de uso; o foco da análise dos casos de uso recai originalmente sobre as interações e atividades das entidades enquanto “caixa-preta”, e não aos seus atores e participantes. A multiplicidade de visualizações que se refere ao modelo do sistema, embora forneça uma estrutura capaz de detalhar a descrição do sistema no contexto de seus artefatos, é de difícil gerenciamento. O maior entrave para o correto uso e gerenciamento das visualizações do sistema é mantê-los alinhados e consistentes em relação uns aos outros. Com tal característica, para garantir a consistência e evitar a perda de informações críticas durante a concepção do sistema, deve-se aplicar uma extensa variedade de relações entre diferentes visualizações e seus modelos correspondentes. Além disso, diferentes níveis de detalhe são suportados

55 por diferentes níveis de modelo. E, embora a metodologia empregada (use-case flowdown) seja concreta e coerente, sua aplicação é um processo complexo que requer um grande domínio de seus mecanismos e estrutura. De toda a sorte, a despeito da complexidade do emprego da metodologia em si, uma característica atraente de sua abordagem é sua adequação ao lidar com múltiplas estratégias de design e implementação. Equipes diferentes de desenvolvedores podem trabalhar num mesmo subsistema UML e desenvolver modelos de design e implementação diferentes (concorrentes), sem que haja perda da rastreabilidade das decisões e escolhas.

3.1.3 Feature-Driven Development (FDD)

O processo FDD (PALMER; FELSING, 2002) foi primeiro introduzido por Jeff de Luca e Peter Coad em 1997, originalmente concebido como um complemento para a técnica Object Modeling in Color (COAD et al., 1999), sendo desacoplado completamente desta só em 2002, quando, após sua revisão, foi considerado suficientemente geral para ser considerado um processo OO independente. Os benefícios alegados na adoção desse processo são: • A entrega de resultados de trabalho tangíveis e frequentes em todos os passos, em ciclos iterativos curtos; • O fornecimento de informações precisas e significativas de progresso e status, com o mínimo de sobrecarga e interrupção para os desenvolvedores. A comunicação através dos níveis hierárquicos da organização se torna fácil, relativamente indolor, oportuna e precisa; • A apreciação de todo o projeto por parte das partes interessadas, gerentes e desenvolvedores. Os participantes do projeto podem ver as áreas de suas atuações à medida que o projeto progride e podem tecer comentários construtivos e oportunos sobre o sistema ainda em desenvolvimento. Apesar da difusão dessa técnica e de seu uso abrangente no desenvolvimento de software, o FDD não pode ser considerado uma metodologia uma vez que, antes de seu início, o estudo de mercado, o planejamento do projeto,

56 o estudo de viabilidade e a permissão para iniciar as atividades de desenvolvimento já foram concluídos. Além dessas atividades, as atividades pós-implementação, tais como, integração, verificação e validação do sistema, implantação e manutenção do sistema são igualmente excluídas de seu ciclo de vida. Como o nome sugere, o FDD é fundamentado na expressão e realização dos requisitos em termos de pequenas peças de funcionalidades com algum valor para o usuário, denominadas features, ou simplesmente, funcionalidades. Cada funcionalidade é uma função/expressão do sistema expressa com o modelo geral: . Cada funcionalidade é identificada como um passo (step) em uma ou mais atividades (activities) ou conjuntos de funcionalidades (features sets). As atividades estão compreendidas em áreas (areas), ou em conjuntos maiores de funcionalidades (major features sets). O processo FDD, exposto na figura 3.2, consiste de cinco subprocessos. Os três primeiros, executados de forma sequencial, são destinados à análise de requisitos e planejamento, enquanto que os dois últimos, recursivamente executados em iterações curtas, são destinados às atividades de design e implementação.

Figura 3.2 - O processo FDD

Fonte: Modificado de PALMER e FELSING (2012)

Desenvolver um modelo geral: Este subprocesso se caracteriza pelo desenvolvimento de um modelo estrutural do domínio do problema, chamado modelo de objeto. Este modelo consiste principalmente de diagramas de classe completos. O modelo de objeto será usado e refinado durante a fase de design por funcionalidades. As atividades desse subprocesso compreendem a formação do time de modelagem, a descrição passo-a-passo do domínio do problema, a revisão e estudo dos documentos de requisitos gerados de maneira tradicional, o desenvolvimento de modelos candidatos, submetidos a revisão por peer review, refinamento do modelo de objeto e a criação de notas sobre o modelo, com algum grau de detalhamento, justificativas e alternativas para referências futuras. Na etapa inicial, o esforço de modelagem concentra-se na abrangência do modelo de objeto e não em sua profundidade e detalhamento; a profundidade é adicionada iterativamente ao longo do ciclo de vida do projeto. Deve-se ter em mente que, do começo ao fim do projeto, o modelo de objeto é o principal veículo em torno do qual as equipes discutem, revisam e esclarecem os requisitos. Elaborar lista de funcionalidades: Decomposição dos requisitos e modelos através da identificação das áreas de funcionalidade do sistema, e das atividades realizadas em cada área. As funcionalidades são identificadas como passos nas atividades e organizadas numa estrutura hierárquica, composta por áreas, atividades e funcionalidades. Para definir os níveis superiores na hierarquia da lista de funcionalidades, a equipe deriva um conjunto de áreas temáticas do domínio da decomposição de alto nível do domínio do problema que os especialistas do domínio usaram naturalmente durante as sessões de modelagem de objetos. Em seguida, para cada área, a equipe identifica suas atividades de negócio (business activities) e aporta funcionalidades individuais dentro de uma dessas atividades. De forma que, hierarquicamente, a lista de funcionalidades tem áreas que contêm atividades que, por sua vez, contêm funcionalidades. Planejar por funcionalidades: Planejamento da ordem de desenvolvimento das funcionalidades, com base nas suas dependências, recursos disponíveis e na complexidade de cada funcionalidade. Outra atividade desse subprocesso é a

59 atribuição de um conjunto de funcionalidades a um grupo de desenvolvedores, considerando o tamanho da equipe, o tempo e os recursos disponíveis para o desenvolvimento. A equipe de planejamento inicialmente sequência os conjuntos de funcionalidades por seu valor de negócio/comercial relativo. Cada conjunto é atribuído a um programador principal (Chief Programmer) que será responsável pelo seu desenvolvimento; no final desse processo, cada programador chefe possuirá um subconjunto da lista de funcionalidades. No decorrer das atividades, a equipe de planejamento pode ajustar o sequenciamento geral dos conjuntos de funcionalidades para levar em consideração riscos técnicos e dependências. Design por funcionalidades: Este subprocesso determina como um conjunto de funcionalidades deve ser implementado por vez, chamado pacote de trabalho (work package). Diagrama de sequência são desenhados para cada funcionalidade atribuída ao grupo, resultando em modificações, adições e refinamentos feitos ao modelo de objeto. Em seguida, uma descrição das classes e métodos usados na implementação da funcionalidade, contendo parâmetros, interfaces, mensagens, dados, etc., é compartilhado entre os demais times envolvidos no projeto. Na prática, em cada iteração forma-se uma equipe de funcionalidade. Uma vez formada a equipe, o programador principal dirige a análise e design das funcionalidades para uma dada iteração. O passo final desse subprocesso é revisar o design. Nesta revisão, o programador principal envolve outros programadores principais ou desenvolvedores que possam analisar o impacto do design proposto sobre os artefatos já gerados e demais designs na iteração. Construir por funcionalidades: Implementação e codificação das funcionalidades. Este subprocesso inclui a realização de testes unitários e, aos itens implementados que passarem pelos testes, a promoção dos itens à construção principal (build), o software em si.

3.1.3.1 Análise e características do processo FDD

A estrutura em camadas do processo FDD permite um gerenciar adequadamente as complexidades dos requisitos e os recursos destinados a cada camada da arquitetura. Além disso, funcionalidades podem ser particionados de acordo com a camada de arquitetura a que pertencem, uma vez que o FDD prescreve uma arquitetura em camadas para sistema de software, fornecendo um meio adicional para gerenciar a complexidade dos requisitos através do particionamento da arquitetura das funcionalidades. Todavia, na adoção do “design orientado a funcionalidades”, a evolução de um design ocorre com a adição, subtração ou modificação de funcionalidades, o que demanda um esforço hercúleo na rastreabilidade e análise dos impactos desta evolução sobre o sistema e demais funcionalidades implementadas. No FDD, ao contrário de outras abordagens baseadas em metodologias ágeis tais como Scrum ou eXtreme Programming, a construção de um modelo de objeto não aparenta representar uma atividade custosa e longa e nem requer um vasto domínio de ferramentas específicas. Em vez disso, a construção de um modelo de objeto inicial no FDD parece ser uma atividade altamente iterativa e colaborativa. A ideia é que os membros da equipe, tanto desenvolvedores quanto usuários e demais partes interessadas, obtenham uma compreensão compartilhada do domínio do problema. Ao fazê-lo, presume-se que a equipe desenvolveria um vocabulário compartilhado e um entendimento comum, o que Eric Evans (2004) chama de linguagem ubíqua. Porém, quando posto sob a ótica de pesquisa aplicada e a interdisciplinaridade inerente em seu empreendimento, desacredita-se a viabilidade ou mesmo a capacidade em se construir tal linguagem ubíqua em tempo oportuno e sem um grande ciclo de aprendizagem. Na construção da lista de funcionalidades, a prática adotada no FDD sugere uma formalização das funcionalidades já discutidas durante o desenvolvimento do modelo de objeto. A premissa defendida neste processo declara que esta estratégia não só evita os problemas decorrentes da não participação dos especialistas de domínio e clientes na formalização e decomposição do sistema, como fornece um

61 mecanismo consistente para expressar as funcionalidades através do uso da linguagem ubíqua criada. Entretanto, esta premissa, apesar de parecer válida no contexto de desenvolvimento de software e suas interfaces com o usuário, torna-se impraticável no contexto de inovação, onde não há definição clara das interações entre usuários e sistemas, tampouco de seus desejos e objetivos. Ao atribuir um subconjunto da lista de funcionalidades a um programador principal, o FDD se afasta do pensamento tradicional das metodologias ágeis na medida em que escolhe não adotar a propriedade coletiva do código-fonte. Essa característica confere robustez ao processo de desenvolvimento, pois incumbe ao programador principal a responsabilidade sobre a integridade conceitual de sua lista de funcionalidades e classes correspondentes. Outra consequência dessa atribuição, é que esta implica em responsabilidade e não em exclusividade. Isso permite que um programador principal autorize que um outro desenvolvedor faça mudanças em uma das classes que possua de forma controlada, verificável e rastreável.

3.2 CARACTERÍSTICAS DESEJÁVEIS À INOVAÇÃO

As metodologias, processos, meta-processos e frameworks investigados não atendem os anseios da pesquisa aplicada de engenharia e da inovação, nem foram pensadas para tal; mesmo naquelas voltadas para a pesquisa, a exemplo da DSRM, do inglês Design Science Research Methodology (PEFFERS et al., 2008), não há, ou não se configura, qualquer vínculo entre sua estrutura e a prospecção, internalização, apropriação, transformação e transferência do conhecimento dentro de um ciclo de pesquisa continuada. Contudo, da problematização, investigação e análise, pôde-se identificar as seguintes características e requisitos desejáveis à inovação que devem compor um processo ou metodologia alvo: Clareza nas definições e processos: O processo deve ser racional, detalhado, de fácil compreensão e bem documentado.

A estrutura do documento de especificação do processo deve ser centrada no ciclo de vida (fases, atividades e transições), abrangendo, além do processo em si, uma visão de seus artefatos ao longo do desenvolvimento, a exemplo do framework RUP SE que faz uso abrangente de diferentes pontos de vista em sua documentação, permitindo a compreensão de seu processo e artefatos pelos mais variados tipos de profissionais envolvidos com o desenvolvimento do projeto ou pesquisa. A ideia de racionalidade e fácil compreensão do processo deve aproximá-la do processo FDD, que possui uma estrutura intuitiva e artefatos simples e coerentes a cada etapa do processo, e distanciá-la de frameworks como o RUP SE, que apresenta uma complexidade inata e uma confusão no uso e função de seus artefatos. Aderência às normas e políticas aplicáveis: O processo deve ser capaz de fornecer os artefatos necessários à adesão com um conjunto de normas e políticas (internas e externas), a exemplo do RUP SE que, pautado no RUP, possui um conjunto de artefatos que, apesar de extremamente complexo e intrincado, torna-o coalescente com normas e políticas corporativas. Cobertura: O processo deve satisfazer as fases genéricas de um ciclo de vida de desenvolvimento (Análise, Design, Implementação e Teste). O processo deve abranger todas as fases e etapas de criação envolvidas no ciclo de vida de um projeto de pesquisa, desde a concepção até sua construção e transferência do conhecimento, e prover artefatos e suporte para pesquisa continuada. Numa analogia ao desenvolvimento de produtos, o processo deve prover seus artefatos numa abordagem similar àquela aplicada na metodologia OOSEM. Uniformidade: O processo deve possuir transições suaves e uniformes entre fases e atividades. O uso de um conjunto específico de modelos e seu refinamento contínuo através do ciclo de vida do projeto, a exemplo dos modelos de objetos do processo FDD, parece a mais bem-sucedida estratégia para o problema da uniformidade durante a transição entre fases.

Rastreabilidade: Os artefatos devem ser rastreáveis direta ou indiretamente aos requisitos e aos objetivos da pesquisa. Realizações indiretas dos requisitos compreendem artefatos de comunicação entre as partes interessadas e os desenvolvedores que devem ser tangíveis para ambos, tal qual a lista de funcionalidades no FDD. Neste processo a rastreabilidade é majoritariamente indireta e, uma vez que seu desenvolvimento consiste num refinamento contínuo de um conjunto de artefatos iniciais, a rastreabilidade de todos os artefatos, decisões e escolhas é realizada através da lista, e da lista aos requisitos. Coerência dos artefatos: Os artefatos devem ser compreensíveis, simples, palpáveis e suficientes. Os artefatos gerados no decorrer do ciclo de vida adotado no processo devem ser complementos uns dos outros, de forma que dois artefatos não sirvam ao mesmo propósito, e devem ser suficientes ao desenvolvimento do projeto, reduzindo o número e a complexidade do gerenciamento desses. Neste sentido uma boa referência no uso dos artefatos vem da metodologia OOSEM e do processo FDD, ambos com um uso muito consciente dos artefatos e de suas funções no processo de desenvolvimento. Gerenciamento de ponta-a-ponta: O processo deve dar suporte às atividades de gerenciamento e acompanhamento. As atividades de gerenciamento (mitigação de risco, estudos de viabilidade, cronogramas, etc.) devem ser incorporadas ao processo através de um desenvolvimento iterativo-incremental de validação contínua, a exemplo da OOSEM e do FDD, centrada na ampla difusão de informações e na comunicação e colaboração intra e inter-times, como visto no framework RUP SE e no processo FDD. Independência intra e inter desenvolvimento: O processo deve, a cada iteração do desenvolvimento, garantir que os artefatos necessários ao desenvolvimento existam e estejam “maduros” o suficiente para o desenvolvimento. Deve ainda permitir a ampla comunicação com as partes envolvidas e interessadas durante todo o ciclo da pesquisa, estratégia similar àquela empregada no processo FDD, incentivando a massiva participação das partes interessadas nas especificações e

64 validação das funcionalidades e, ao mesmo tempo, garantindo independência dos times no desenvolvimento dos grupos de funcionalidades. Ferramenta-independente: O processo deve ser independente de ferramentas ou linguagens. Neste ponto em particular entendeu-se que a maior limitação das metodologias e processos estudados era a forte dependência com determinada linguagem ou ferramenta, que, de certa forma, desestimula contribuições ou visões externas sobre determinado artefato, comportamento ou função do sistema. Validação contínua: O processo deve promover a contínua validação dos artefatos durante todo o ciclo de vida. Técnica adotada pelo processo FDD, a validação contínua deve dar suporte a artefatos com diferentes maturidades e granularidade. Pesquisa: O ciclo de vida empregado no processo deve contemplar as atividades de uma pesquisa acadêmica. Deve-se considerar, por exemplo, a publicação dos resultados à academia e a pesquisa continuada, onde um pesquisador desenvolve seu trabalho dentro de um programa ou sobre a pesquisa de outrem, como atividades pertencentes ao processo.

4 ARQUÉTIPO E DESIGN DO PROCESSO ARES

Independentemente sob qual perspectiva analítica se observe o processo de inovação, é a gestão do conhecimento, enquanto construção sistemática de conhecimento e de sua aplicação, seu fator impulsionador. E, independentemente da abordagem de gestão do conhecimento, seja na sistemática da gestão do conhecimento de Wiig (1993) ou na transformação de bens intelectuais de Barclay e Murray (1997), são nos processos de comunicação, como observa Theunissen (2004 apud LEITE, 2006), que se encontra a pedra angular da gestão do conhecimento. No contexto tecnológico, em âmbito organizacional, estes processos se referem não somente ao ato de tornar a informação disponível interna e externamente, mas, sobretudo, em fazer com que o conhecimento técnico, útil e específico, seja distribuído de forma oportuna e compreensível às pessoas certas. Entretanto, no contexto da pesquisa aplicada de engenharia, como observa Leite (2006), embora seja possível encontrar na literatura especializada estudos sobre gestão de conhecimento no contexto acadêmico, esses estudos não consideram a natureza peculiar do conhecimento científico ou de seu ambiente. Essa aparente deficiência na gestão do conhecimento se transpõe, e foi evidenciada, na investigação e análise das metodologias (Capítulo 3), destacando- se: • A ausência de mecanismos explícitos para aquisição, retenção, apropriação, transformação e transferência do conhecimento. • A forte ligação daquelas metodologias com um conjunto específico de ferramentas e/ou linguagens. • O vínculo dessas metodologias com a engenharia de software. Estas características levaram à consideração da especificação e criação de uma metodologia ou processo capaz de endereçar as características e requisitos desejáveis à inovação, identificados no decorrer da investigação e análise e listados no Capítulo 3, Seção 3.2. Essa consideração traz consigo riscos e dificuldades não ponderados até o momento, como o risco de acabar com um “colosso com pés de barro” ou um

66 processo descartável. Riscos que só poderão ser mitigados ou contingenciados sob a outorga do tempo. A especificação de metodologias e processos é assunto recente e sua formalização enquanto disciplina só foi pensada no final dos anos 90, no contexto dos sistemas de informação e sob o título engenharia do método (method engineering), termo proposto por Brinkkemper (1996). A literatura descreve inúmeras técnicas para a especificação e design de uma metodologia. A profusão dos métodos existentes foi ordenada e classificada por Ralyté et al. (2004) em quatro grupos: Ad-hoc, Paradigm-based, Extension-based, Assembly-based, posteriormente ampliados e redefinidos por Ramsin (2006) em sua tese, como se segue: • Ad-hoc: Construção de uma metodologia do zero. • Paradigm-based / Instantiation approach: Instanciação, abstração ou adaptação de um meta-modelo existente para a construção de uma metodologia. • Extension-based: Aprimoramento ou extensão de uma metodologia com novos conceitos e propriedades. • Assembly-based / Composition approach: Construção de uma metodologia ou sua modificação através da reutilização de partes de outras metodologias. • Integration approach: Construção de uma metodologia através da integração de propriedades, ideias, técnicas e métodos de metodologias existentes. • Artefact-oriented approach: Construção de uma metodologia através, e em torno, da elaboração de uma cadeia complementar e contínua de artefatos. O processo ARES, do inglês Applied Research in Engineering Science, centrado em modelagem e simulação para pesquisa aplicada em engenharia, proposto nesta dissertação, foi estruturado sob uma estratégia híbrida de design, similar à estratégia usada por Ramsin (2006), porém, diferente da abordagem empregada pelo autor, buscou-se, na aplicação de diferentes métodos, prover convergência entre visões de design top-down, bottom-up e/ou middle-out em cada iteração.

4.1 DESIGN HÍBRIDO

A estratégia híbrida de design empregada para o processo ARES, apresentada na figura 4.1, foi idealizada sobre um ciclo incremental-iterativo- evolutivo. Nesta estratégia, o design é engendrado sobre dois motores iterativos, um macro-ciclo evolutivo, onde o processo é visto sob uma perspectiva top-down – partindo de uma abstração de ciclo de vida para a especificação detalhada de cada fase e atividade – e ciclos de desenvolvimento incremental internos ao macro-ciclo, onde fases, atividades e subprocessos são abordados sob as óticas top-down, middle-out e bottom-up.

Figura 4.1 - Estratégia de design do processo ARES

Fonte: Autoria própria

Atribuição de um meta-processo como abstração para o processo: Ponto de partida do design do processo, esta atividade atribui ao design um meta-processo como abstração de seu arquétipo. A escolha deste meta-processo deve ser guiada

68 pelos requisitos e características que impactam o ciclo de vida diretamente, como cobertura, gerenciamento de ponta-a-ponta e validação contínua. Análise da abstração quanto a estabilidade: Esta atividade inicia o macro-ciclo evolutivo. Nela, a especificação do processo é analisada quanto a granularidade, a fim de garantir que todas as fases e atividades são compatíveis entre si e em relação ao grau de granularidade empregado na iteração do macro-ciclo. Análise da abstração quanto a cobertura: O objetivo desta atividade é garantir que a especificação do processo em construção satisfaz os requisitos e características desejáveis identificados para este. Definição de um escopo para o design: O escopo de design é um subconjunto de sub-processos, fases ou atividades do processo. Esta atividade define, para cada subconjunto, e para cada iteração, o grau de abstração e granularidade que o design deve atender. Decomposição do escopo sob as óticas top-down, middle-out e bottom-up: Atividade que inicia o ciclo de desenvolvimento incremental. Esta atividade busca esmiuçar o objeto em desenvolvimento com o intento de tornar a especificação mais sólida e completa. Na perspectiva top-down, parte-se do estado atual do objeto e o decompõe em unidades menores até atingir o grau de abstração requerido pelo escopo. Sob o ponto de vista bottom-up, trilha-se um caminho inverso à decomposição top-down, partindo do resultado esperado do design para recompor o estado atual do objeto. Já na ótica middle-out, os impactos de estruturas com um menor grau de abstração sobre os demais elementos do processo são analisados com o objetivo de se definir interfaces e restrições a estes elementos. Aplicação de estratégias de design: Seleciona a estratégia de design a ser aplicada na iteração do ciclo de desenvolvimento atual considerando a perspectiva adotada na atividade anterior. Das estratégias listadas no início deste capítulo algumas se aplicam, ou se adequam melhor, ao ponto de vista adotado, a saber: • Na perspectiva top-down, as estratégias aplicáveis são a paradigma-based e a extension-based; • Sob a ótica middle-out, aplicam-se a assembly-based e a integration approach;

• Sob o ponto de vista bottom-up, as estratégias que melhor se adequam são a artefact-oriented approach e a integration approach. Integração do resultado do design à abstração: O resultado do design aplicado sobre o escopo, após sua decomposição, é integrado à especificação. A nova abstração gerada desta integração é submetida a decomposição, sob uma nova perspectiva, realimentado o ciclo de desenvolvimento incremental. Revisão e atualização da abstração: A abstração é revisada, atualizada e refinada para acomodar as modificações realizadas durante o design. O processo de design se dá por terminado quando produzir uma especificação detalhada o suficiente das interfaces entre fases e macro-atividades. Neste ponto o processo é definido e implementado, concluindo seu desenvolvimento.

4.2 PROGRESSÃO DO DESIGN

A estratégia híbrida de design, descrita na seção 4.1, foi aplicada usando como ponto de partida os requisitos e características desejáveis à inovação, identificados no decorrer da análise e investigação do cânone de metodologias. A progressão do design, resumida nas figuras 4.2 a 4.5, e os métodos usados em alguns dos ciclos são apresentados e justificados de forma a compor uma sequência racional e lógica de desenvolvimento do processo ARES.

Figura 4.2 - Primeira abstração do processo ARES

Fonte: Autoria própria

Abstração #1: Com um alto grau de generalização, a primeira abstração é o resultado da primeira atividade do design. A escolha do meta-processo para povoar o design, e servir de eixo fundamental do processo em desenvolvimento, considerou

70 os requisitos de clareza, cobertura, uniformidade, validação contínua e gerenciamento de ponta-a-ponta; como resultado, um ciclo de vida “Vee” (MUNASSAR; GOVARDHAN, 2010), similar àquele aplicado na metodologia OOSEM, foi atribuído à Abstração #1. A estrutura sequencial de suas atividades, apesar de rígida, concede ao ciclo “Vee” clareza e simplicidade, abrangendo as fases essenciais (Análise, Design, Implementação e Teste) para o desenvolvimento de sistemas em um processo contínuo e coeso, onde cada fase, antes de ser concluída, deve ser verificada frente a fase anterior. Além de sua estrutura, a uniformidade das transições e a coerência de seus artefatos concedem a este modelo a capacidade de reconhecer, com certa antecedência, desvios de planejamento e riscos, garantindo transparência do processo e gestão de ponta-a-ponta. O processo orientado a requisitos desse ciclo de vida enfatiza 1) o teste, através do desenvolvimento de procedimentos de teste e aceitação antes que qualquer implementação ser realizada, e 2) a rastreabilidade, relacionando cada elemento do design e cada teste a um ou mais requisitos, endereçando cada requisito a pelo menos um elemento de design e um teste correspondente, garantindo que nada seja feito desnecessariamente. Isso implica em que tudo quanto for suficiente para atingir os critérios de aceitação será realizado.

Figura 4.3 - Segunda abstração do processo ARES

Fonte: Autoria própria

Abstração #2: Esta abstração foi povoada majoritariamente através da aplicação das estratégias Extension-based e Composition approach, reestruturando as fases e atividades do modelo “Vee”, meta-processo base do processo proposto, com a incorporação dos conceitos da meta-metodologia Model-Driven Architecture™ (MDA) da Object Managment Group® (KLEPPE; WARMER; BAST, 2003). A

71 assimilação destes conceitos orienta o processo ao desenvolvimento de modelos, conferindo-lhe flexibilidade, uniformidade e clareza sem associá-lo a ferramentas ou linguagens específicas. Os conceitos MDA definem uma abordagem que separa a especificação do sistema e suas funcionalidades da especificação de sua implementação em uma plataforma específica. Desta forma, um sistema é concebido através do refinamento e da transformação sucessiva de modelos, numa estrutura de modelagem contínua e evolutiva (KARDOS; DROZDOVÁ, 2010). Iniciada com a construção dos modelos independentes de computação, ou CIM (Computer Independent Models), que representam o comportamento esperado do sistema, integrando o conhecimento dos “práticos” e especialistas do domínio do sistema (ou negócio) com aqueles que o desenvolverão. Essa meta-metodologia permite que os desenvolvedores construam sistemas de acordo com a lógica de negócios e os dados existentes, independentemente de qualquer plataforma tecnológica particular, com a elaboração de modelos independentes de plataforma (PIM – Platform Independent Models). Estes sistemas são “aportados” em uma ou mais soluções tecnológicas, combinando especificações dessas tecnologias aos PIM, transformando-os em modelos dependentes de plataforma (PDM – Platform Dependent Models, ou PSM – Platform Specific Models), e estes em modelos de implementação (IM – Implementation Models). A noção de transformação de modelo é fulcral na abordagem MDA. Para incorporar essa noção explicitamente no processo em desenvolvimento, a fase de Análise (Abstração #1) foi decomposta em Exploração, onde o negócio, já definido, delimita os objetos da pesquisa e onde os CIM são engendrados, e Análise, na qual o sistema é definido em “caixa-preta” e os PIM são modelados. A fase de Design (Abstração #1) foi segmentada em Arquitetura, onde a infraestrutura do sistema define as plataformas e onde os requisitos sensíveis à escolha tecnológica, não- funcionais, são endereçados e resolvidos, e Design, onde modelos PIM são transformados em PDM e “aportados” na arquitetura.

A fim de estabelecer atividades para a comunicação acadêmica dos resultados e para a definição de roteiros para a pesquisa continuada, foi adicionada a fase de Transição ao design da metodologia proposta.

Figura 4.4 - Terceira abstração do processo ARES

Fonte: Autoria própria

Abstração #3: O foco nessa etapa do design foi adicionar, usando principalmente estratégias de Artefact-oriented e Integration approach, características da modelagem e de processos orientados a modelos, introduzidos na abstração anterior, aos subprocessos do arquétipo criado. As características dos modelos PIM e PDM, agora entendidos como artefatos do processo, foram envelopadas num conjunto de atividades específicas. Foi concebida primeiro a Modelagem conceitual, contida na fase de Análise e responsável pela criação dos modelos PIM. Esta cadeia de atividades capta os aspectos estruturais, funcionais e comportamentais do domínio do problema; os requisitos funcionais do sistema, entendido como uma “caixa-preta”, são capturados e suas interfaces e interações com o meio são especificadas. O desenvolvimento então concentra-se no sistema em si, e uma visão preliminar de sua estrutura é idealizada ainda na fase de Análise. O modelo preliminar do sistema é refinado durante a fase de Arquitetura, e detalhado com as informações e restrições das tecnologias que compõem a arquitetura, e da arquitetura em si, para compor os PDM na fase de Design (processo cingido na cadeia de atividades Modelagem de sistema). Os modelos dependentes de plataforma são então utilizados como base para a implementação através da transformação destes em modelos IM. O conjunto de atividades Fabricação e Codificação faz a transição entre o esforço de modelagem e a prototipação e “produtação” do sistema, enquanto que a

cadeia de Verificação e Validação fornece as evidências de que a implementação do sistema satisfaz os requisitos e anseios das partes interessadas. Cada uma das sequências de atividades introduzidas nessa abstração foi aperfeiçoada durante sucessivas iterações do processo de design. As dependências e artefatos foram identificados e as atividades de modelagem e planejamento correspondentes, foram adicionadas aos subprocessos pertinentes.

Figura 4.5 - Quarta abstração do processo ARES

Fonte: Autoria própria

Abstração #4: O esforço empregado nesta abstração foi o de harmonizar as atividades de controle e gerenciamento de processos, incorporadas ao ARES majoritariamente através das estratégias de Artefact-oriented e Integration approach, com as atividades de modelagem e os subprocessos. Ao longo do processo de coadunar esses universos, atividades foram incorporadas e a própria cadeia de desenvolvimento foi refinada e alterada corroborando para a uniformidade e clareza do processo. A primeira grande mudança na cadeia de desenvolvimento se deu na partição da cadeia de Modelagem de sistema (Abstração #3) nas cadeias de Modelagem de sistema e de Encapsulamento e Particionamento. Nesta nova abordagem da cadeia de Modelagem de sistema, o modelo do sistema é concebido como uma extensão do domínio do problema e entendido como uma de suas entidades, tornando este modelo tangível tanto para especialistas do domínio do problema quanto para desenvolvedores. Na cadeia de Encapsulamento e Particionamento, compreendida na fase de Design, as estruturas internas do sistema são definidas

74 e a modelagem torna-se plataforma-dependente com a transformação de modelos do domínio do problema (PIM) em modelos de sistema de arquitetura específica (PDM). Tratar a modelagem do sistema como uma modelagem transicional, permite abarcar o distanciamento entre o “mundo-real” e a modelagem no domínio da solução (sistema). Como resultado, há um incentivo e um favorecimento a interação entre os especialistas do domínio do problema, e demais partes interessadas, e os desenvolvedores, facilitando não só o processo em si, mas também seu controle e gerenciamento. Numa segunda rodada os subprocessos Design e Implementação e teste foram reestruturados num ciclo incremental/evolutivo. Em cada iteração do ciclo de desenvolvimento, um escopo de implementação é selecionado do modelo do sistema, encapsulado em subsistemas e refinados em PDM e posteriormente em modelos IM, que são por fim implementados e verificados. Ao final do ciclo incremental/evolutivo, o sistema é integrado, verificado e validado. Durante o processo de design da metodologia, o foco é sempre voltado para o desenvolvimento em si. Na última etapa deste processo, porém, este foco foi direcionado para as atividades de gestão. Como resultado, dois conjuntos de atividades foram adicionados: 1) Arrematando todo o processo de desenvolvimento e conhecimento gerado a partir deste, constituindo a cadeia principal da fase de Transição; 2) inserido na fase de Exploração, tornando lógico e justificável o começo das atividades de desenvolvimento, prevendo desde considerações sobre a viabilidade e o “valor” agregado ao projeto, até a elaboração de critérios e de frentes de ação, dano início as atividades de gerenciamento e controle e ao projeto de pesquisa em si.

4.2.1 O arquétipo do processo ARES

A abordagem adotada na confecção do processo proposto fundamenta-se na fluidez das transições entre subprocessos, desde a concepção do problema e seu domínio até a implementação da solução. Para tanto, o processo ARES utiliza-se

75 de transformações iterativas de modelos através do particionamento, ou redistribuição, de funcionalidades e da introdução do conceito de interoperabilidade conceitual entre modelos (TOLK et al., 2007), que define o grau de maturidade dos modelos esperado para cada fase do desenvolvimento. O processo ARES apresenta o seguinte encadeamento de subprocessos: 1. Modelagem cognitiva e plano de desenvolvimento preliminar 2. Modelagem conceitual e engenharia de requisitos 3. Modelagem e especificação do sistema 4. Particionamento e design da arquitetura do sistema 5. Desenvolvimento incremental/evolutivo 5.1. Encapsulamento 5.2. Implementação e teste 5.3. Validação 6. Transição

4.2.1.1 Modelagem cognitiva e plano de desenvolvimento preliminar

Há duas etapas distintas na fase de exploração. A primeira delas objetiva o planejamento e organização da pesquisa, delineando o projeto, sua natureza, escopo, riscos, viabilidade e restrições. Nesta etapa, o ciclo de vida da pesquisa deve ser concebido e a transferência do conhecimento por ela gerado, planejada. Tratando-se de pesquisa aplicada, não há necessariamente uma entidade capaz de validar seu desenvolvimento ou definir claramente seus critérios de aceitação. Mesmo que um pesquisador ou pesquisador chefe possa, por vezes, desempenhar este papel, sua atuação é ilegítima, pois, sendo membro atuante da pesquisa, seu julgamento está eivado com seu envolvimento no desenvolvimento e desenrolar da mesma. Neste sentido, a academia é a única capaz de validar o resultado de uma pesquisa de maneira idônea e em pleno direito. Isto posto, cabe a adição de uma etapa acessória, vinculada à etapa de planejamento, com a finalidade de preparar e planejar artefatos de divulgação técnico-científica que, em

76 conjunto, validem o conhecimento sobre o domínio o problema, o desenvolvimento e os resultados da pesquisa. A segunda etapa tem por objetivo o levantamento de contexto da pesquisa e a aquisição de conhecimento sobre o domínio do problema e sua natureza, sob a ótica da modelagem cognitiva. Esta modelagem, apresentada sob a forma de modelos declarativos e CIMs, sintetiza a prospecção das informações técnico- científicas do conhecimento relativo ao domínio do problema. Esta etapa é concomitante ao “negócio”, porém, neste momento, tanto as justificativas e objetivos, quanto os stakeholders da pesquisa, já são conhecidos e entende-se a relevância de sua realização.

4.2.1.2 Modelagem conceitual e engenharia de requisitos

Este subprocesso é a pedra angular do processo de validação sucessiva, sendo a modelagem conceitual a referência para todo o desenvolvimento. Esta atividade consiste de modelagem computacional, associada à cenários e constraints, e da definição do ambiente de simulação pretendido. Esse subprocesso objetiva a inserção do sistema como contradomínio do problema, definindo suas interfaces, interações e comportamentos, tento como etapas: 1. Modelagem do domínio do problema: Com o foco na criação de cenários simuláveis, a modelagem do domínio do problema deve abranger não só as características “funcionais” do domínio, mas considerar os contextos e cenário adjuntos, tais como os cenários de safety/security, e os constraints associados a cada cenário. Nesta etapa deve-se ainda considerar as características não-simuláveis do domínio do problema, como os requisitos de confiabilidade, através de modelos e/ou requisitos declarativos. 2. Modelagem em “caixa preta”: O sistema, entendido como contradomínio do problema, é modelado em termos de suas interfaces, comportamentos e interações com o domínio do problema e representado como componente constituinte dos cenários. Os sistemas acessórios e adjuntos ao sistema em

desenvolvimento devem ser igualmente modelados nessa etapa e suas interações devem ser definidas. 3. Validação conceitual: Esta etapa inicia o processo de validação contínua com a criação de casos de validação (workbench de validação), escolhidos dos diferentes cenários simuláveis. Cada caso de validação, composto por entradas conhecidas e saídas esperadas, alicerçadas em premissas, comportamentos e interações conhecidas, deve considerar um conjunto de requisitos e características funcionais do sistema, de forma que a somatória de todos os casos de validação contemple a totalidade dos objetivos e escopo da pesquisa. Por fim, para cada caso de validação ou cenário, definem-se as métricas e análise associadas.

4.2.1.3 Modelagem e especificação do sistema

Com o foco no domínio da solução (contradomínio), a fase de modelagem e especificação do sistema elenca as estratégias e soluções possíveis para o domínio do problema. Para cada sistema possível, definem-se suas macro-funções, as unidades ou blocos fundamentais de função ou comportamento, suas interações e particularidades. Com base nas especificações dessas interações e constraints, e em critérios não necessariamente ligados ao domínio do problema, a exemplo da viabilidade, know-how ou tempo hábil de execução, um sistema candidato é escolhido e suas macro-funções modeladas. Assim como para o sistema em si, espera-se mais de uma solução possível para uma dada macro-funções. Porém, diferente da análise a priori que determina um sistema candidato, a determinação de uma solução única para uma macro- função é uma análise a posteriori dos impactos desta solução particular no sistema. Desta análise, um modelo candidato da macro-função é escolhido para compor o modelo do sistema a ser implementado. Por fim, o sistema candidato é validado em ambiente simulável e um workbench de verificação do sistema é criado.

1. Sistema candidato: A escolha de um sistema candidato sintetiza e consolida o entendimento do domínio do problema. Com um foco mais abrangente do que a solução unicamente, a escolha de um sistema candidato deve considerar o ecossistema de desenvolvimento, de forma que: para cada solução ou estratégia possível, um conjunto de riscos associados deve ser levantado e analisado. Desta análise, um sistema candidato deve ser escolhido e seus riscos associados devem ser mitigados. 2. Modelagem em “caixa cinza”: Com a escolha do sistema candidato, o esforço de modelagem deve se concentrar no sistema propriamente dito, transferindo o foco do domínio do problema para seu contradomínio. Nesta etapa, o sistema deve ser decomposto em macro-funções, ou seja, em unidades ou blocos fundamentais de função ou comportamento. Para cada macro-função, suas interações e interfaces devem ser definidas e modeladas. 3. Catálogo de soluções aplicáveis às macro-funções: Para cada macro-função especificada, existe pelo menos uma solução que equaciona suas propriedades. Cada solução aplicável identificada deve ser modelada, caracterizada e catalogada. 4. Modelagem em “caixa branca”: Do catálogo de soluções aplicáveis às macro- funções, um subconjunto de modelos é selecionado para compor o modelo do sistema a ser implementado de forma a garantir a interoperabilidade entre esses modelos e a manter a característica computacional simulável do sistema. 5. Validação sistêmica: No processo de validação sistêmica, o modelo em “caixa preta” (Modelagem conceitual) é substituído pelo modelo em “caixa branca” nos cenários simuláveis do workbench de validação. 6. Workbench de verificação e interoperabilidade: Neste workbench, preocupa- se com as interações e comportamentos específicos de cada macro-função. Para o conjunto de macro-funções que compõem o sistema, criam-se cenários de interoperabilidade que esgotam as interações possíveis entre esses blocos fundamentais. Para cada cenário, métricas e análises associadas são definidas.

4.2.1.4 Particionamento e design da arquitetura do sistema

O subprocesso de particionamento e design da arquitetura do sistema é uma ponte entre especificação e implementação. Iniciando o mecanismo de desenvolvimento incremental/evolutivo, este subprocesso se pauta num levantamento tecnológico, realizado para entender as características do sistema a ser implementado. Do repertório tecnológico, define-se a arquitetura do sistema com base na análise dos impactos de uma tecnologia particular sobre o sistema e sobre o processo de desenvolvimento em si. Da arquitetura do sistema, especifica-se o conjunto das características, constraints e interfaces das diferentes tecnologias empregadas. Ao final do particionamento, cada macro-função é aportada numa ou mais tecnologias, indicando a premissa de encapsulamento e implementação do sistema. Agindo como acionador do mecanismo de desenvolvimento incremental/evolutivo, o particionamento é um subprocesso complementar que favorece a lógica do processo e dá coesão às atividades de desenvolvimento. Esta característica faz com que o particionamento não seja um subprocesso autocontido cuja execução possa ser validada.

4.2.1.5 Desenvolvimento incremental/evolutivo

Há, neste subprocesso, dois ciclos de desenvolvimento entrelaçados entre si: um macro-ciclo e um ciclo interno. No macro-ciclo, a estratégia sistêmica da implementação da arquitetura e as interfaces são especificadas e caracterizadas. Com a estratégia definida, o ciclo interno é iniciado. Este ciclo é tipificado por rodadas rápidas de encapsulamento, implementação e teste das macro-funções e de secções da arquitetura do sistema. Com a finalização do ciclo interno, o macro-ciclo é retomado com a realização da validação da implementação. Em caso de falha nesta validação, o macro-ciclo é reiniciado e uma nova abordagem para a estratégia sistêmica é proposta. Já em

80 caso de sucesso, o processo avança para a validação acadêmica, instituindo o subprocesso de transição. Em resumo: 1. Estratégia sistêmica e especificação de interfaces, tipos e dados: O foco desta atividade é resolver o fluxo de sinais, mensagens e dados e as interfaces entre as macro-funções e as tecnologias empregadas. Com a estratégia definida e as interfaces especificadas: 1) as premissas de encapsulamento são analisadas; 2) o sistema é segmentado em módulos de implementação; e, 3) as restrições impostas a cada módulo de implementação, macro-função ou secção da arquitetura são elencadas. 2. Encapsulamento: Esta atividade visa a transformação dos modelos PIM em modelos PDM e a criação de modelos de abstração tecnológica, que emulam, em ambiente simulável, a estratégia sistêmica sob as premissas da tecnologia empregada. Por fim, métricas e um workbench de verificação dos módulos de implementação são criados. 3. Validação da estratégia sistêmica: Na validação da estratégia sistêmica, o modelo encapsulado do sistema é aplicado aos cenários do workbench de validação em substituição ao modelo em “caixa preta”. 4. Implementação e teste: Nesta etapa os modelos PDM dos módulos de implementação são engendrados em modelos IM. Cada modelo de implementação é então implementado e testado segundo as métricas de verificação aplicáveis e ao workbench correspondente. 5. Validação da implementação: A validação da implementação é iniciada com a implementação/execução dos cenários do workbench de validação. Para cada cenário o sistema é posto em operação e os resultados desta operação são comparados aos da validação da estratégia sistêmica.

4.2.1.6 Transição

Centrada na divulgação acadêmica e na transferência do conhecimento adquirido ao núcleo onde a pesquisa está situada, o subprocesso de transição é detentor da conclusão e desfecho da pesquisa aplicada. Suas atividades objetivam

81 a coesão e coerência do esforço empregado na pesquisa e endereça à academia o juízo sobre a lidimidade e validade da pesquisa e de seus resultados.

4.3 O DESIGN SOB A ANÁLISE DOS REQUISITOS

Buscou-se, no design e arquétipo do processo ARES, um grau de especificação suficiente para a definição clara e precisa do escopo dos subprocessos e atividades, sem entrar em suas minúcias e detalhes. Como etapa final do esforço de design do processo e a fim de assegurar sua qualidade e garantir que o esforço empregado em seu desenvolvimento será apropriadamente direcionado, faz-se necessário a análise de seu arquétipo contra as características e requisitos desejáveis à inovação (ver Capítulo 3, Seção 3.2). Esta análise expõe como cada requisito foi abordado no design do processo, assinalando os requisitos não resolvidos, ou não endereçados. Abaixo sumariza-se o empenho de análise aplicado ao design do processo ARES. Clareza nas definições e processos: Na especificação do design do processo, este requisito não é, nem pode ser inteiramente endereçado, visto se tratar de uma restrição à documentação e especificação em si. Entretanto, o encadeamento dos subprocessos e atividades do processo, delineado durante o design, conferem lógica e racionalidade, corroborando para o atendimento deste requisito. Aderência às normas e políticas aplicáveis: Assim como o gerenciamento de ponta-a-ponta, a aderência às normas e políticas aplicáveis não cabe ao processo em si, mas ao ambiente organizacional e ao caráter da pesquisa. Desta forma, a especificação do processo deve evidenciar a rastreabilidade das decisões, e de suas razões, tomadas ao longo do desenvolvimento, incorporando as influências externas e internas ao ciclo de vida da pesquisa aplicada. Cobertura: Evidenciado desde a primeira abstração, com a escolha do meta- processo “Vee” como ponto de partida do arquétipo do processo, a cobertura do processo às fases de um ciclo de vida geral de desenvolvimento, se manteve, explícita e racionalmente, durante todo o design.

Uniformidade: Este requisito foi endereçado ainda no design pela elaboração de um mecanismo de desenvolvimento incremental/evolutivo e pela fluidez induzida nas transições entre os subprocessos, ambas fortemente influenciadas pelo processo FDD, e pela incorporação dos conceitos da meta-metodologia MDA. Rastreabilidade: No design do processo, a rastreabilidade se configura na premissa de refinamento contínuo de seus modelos e artefatos, desde a cognição sobre o domínio do problema até a implementação do sistema solução. Coerência dos artefatos: Os predicados de refinamento contínuo dos modelos e artefatos, atribuído na fase de design, confere simplicidade e tangibilidade ao desenvolvimento. No que concerne à suficiência dos artefatos, propõe-se seja adotada uma estrutura próxima das visualizações do framework RUP SE, e similar ao meta-modelo Systemica™, S*metamodel, (INTERNATIONAL CENTERS FOR TELECOMMUNICATION TECHNOLOGY, 2008) empregado na metodologia PBSE, do inglês Pattern-Based Systems Engineering (THE INCOSE MBSE PATTERNS WORKING GROUP, 2015). Gerenciamento de ponta-a-ponta: O atributo evolutivo dos artefatos no processo ARES em seu ciclo de desenvolvimento, inspirado pelo processo FDD, promove uma estrutura hierárquica do processo, mantendo a coesão e a lógica das atividades e subprocessos, o que permite o acompanhamento e gerenciamento destas atividades em diferentes níveis e granularidades. Independência intra e inter desenvolvimento: O processo de validação contínua prevista no design, e o caráter evolutivo imposto a seus artefatos, atestam a independência de seus subprocessos, respaldando o atendimento a este requisito. Ferramenta-independente: A assimilação dos conceitos da meta-metodologia MDA, permite definir as características de seus artefatos independente do conjunto de ferramentas utilizado pelo desenvolvedor. Uma proposta para assegurar esta propriedade é a inserção do paradigma de interoperabilidade conceitual entre modelos (TOLK et al., 2007), na especificação dos artefatos gerados no processo. Validação contínua: Um mecanismo de validação contínua baseado em cenários simuláveis foi proposto e inserido no arquétipo do processo. Este mecanismo deve ser evidenciado e detalhado na especificação do processo.

Pesquisa: No esforço de design do processo, a pesquisa, enquanto entidade de aquisição, retenção, apropriação e transferência de conhecimento, foi disposta em todas as etapas e subprocessos. Para tornar essa disposição explícita, o processo deve evidenciar as estratégias e o fluxo do conhecimento ao longo das atividades e subprocessos.

5 O PROCESSO ARES

No empenho de desenvolvimento de uma metodologia ou processo, como no apresentado neste trabalho, o meio mais regular e oportuno para divulgá-lo e apresentá-lo para seu público alvo, no caso particular os pesquisadores e engenheiros envolvidos numa pesquisa aplicada, é a escrita de um guia de usuário ou manual de boas práticas. Entretanto, não há um formato padrão para sua elaboração. O requisito de clareza nas definições e processos (ver Capítulo 3, Seção 3.2), define que o processo deve fornecer uma descrição consistente, detalhada, compreensível, clara, racional e precisa do ciclo de vida e seus subprocessos, atividades e artefatos. Para satisfazer este requisito, elegeu-se uma abordagem constituída de três diferentes perspectivas top-down para descrever o processo. As perspectivas através das quais o processo ARES é retratado são: 1. Sob a perspectiva das atividades: Enfatiza o ciclo de vida do processo ARES e o encadeamento de suas atividades. Esta perspectiva expressa a decomposição lógica do processo, os controles exercidos sobre este e suas atividades de gerenciamento e planejamento. 2. Sob a perspectiva do esforço de modelagem: Evidencia as transformações sucessivas dos modelos, a maturidade destes nas diferentes etapas do desenvolvimento e suas características. 3. Sob a perspectiva da gestão do conhecimento: Apresenta o conhecimento como artefato constituinte da pesquisa. Esta perspectiva aponta estratégias para a aquisição, retenção, apropriação, transformação e transferência do conhecimento. Descrever o processo sob três diferentes perspectivas não só destaca as características de cada uma delas, mas também permite aprofundar a descrição de pontos específicos do processo. Desta forma, é possível abordar estratégias e boas práticas para a difusão interna e externa do conhecimento adquirido nas diferentes fases da pesquisa, sob a perspectiva da gestão do conhecimento, ao mesmo passo que, sob a perspectiva do esforço de modelagem, é possível definir o grau de

85 maturidade de um modelo e a estratégia para sua transformação sucessiva. Uma visão geral do processo ARES é apresentada na figura 5.1, onde é possível visualizar as atividades, artefatos e as características dos modelos ao longo de seu ciclo de vida. Os elementos deste diagrama serão definidos ao longo deste capítulo, em momento oportuno.

Figura 5.1 - O processo ARES

Fonte: Autoria própria

5.1 FRAMEWORKS USADOS NO PROCESSO ARES

O processo ARES abarca em seu escopo três frameworks distintos. Dois deles visam conferir robustez, uniformidade e racionalidade às suas atividades e artefatos, a saber: o LCIM (do inglês Level of Conceptual Interoperability Model), ou modelo de níveis de interoperabilidade conceitual (TOLK et al., 2007) e o modelo Rugby (JANTSCH et al., 1999). O terceiro, chamado aqui de triângulo de Couclelis (COUCLELIS, 2010), propõe uma abordagem estruturada para a representação de informações adequada à retenção e apropriação do conhecimento.

5.1.1 LCIM

Sob o viés da engenharia de sistemas, um processo de desenvolvimento requer uma abordagem reprodutível e bem documentada, o que, no contexto de modelagem e simulação, significa a existência de um framework capaz de capturar os artefatos necessários para a interoperação entre os modelos e simulações. No contexto do processo ARES, o framework LCIM, cujas implicações dos níveis de interoperabilidade, anotados de L0 a L6, listadas no quadro 5.1, foi adicionado a fim de lidar com as questões de interoperabilidade da conceitualização do sistema até sua implementação.

Quadro 5.1 - Níveis de interoperabilidade conceitual LCIM

Fonte: TOLK et al., 2007

O modelo dos níveis de interoperabilidade conceitual presente no framework exerce tanto função descritiva quanto prescritiva – característica determinante na escolha desse framework para compor o processo ARES –, resumidas no quadro 5.2. Em sua função descritiva, o LCIM descreve os níveis e propriedades da interoperabilidade existentes dentro de uma composição de sistemas. Já em sua função prescritiva, o framework prescreve os métodos e requisitos que devem ser satisfeitos durante o desenvolvimento de um sistema de sistemas para alcançar um nível desejado de interoperabilidade.

Quadro 5.2 - Papéis descritivos e prescritivos dos níveis do framework LCIM

Fonte: TOLK et al., 2007

Função descritiva: Em sua função descritiva o framework é usado para representar ou analisar as capacidades, propriedades, características e os níveis de interoperabilidade de um sistema ou sistema de sistemas existente. O objetivo é descrever como os sistemas existentes estão interoperando e qual o nível de interoperabilidade conceitual pode ser alcançado pelas abordagens específicas do usuário sem prescrição (TOLK et al., 2007), expondo as lacunas na interoperação entre os sistemas. As características da função descritiva do framework LCIM são: • Sistemas reais ou sistemas de sistemas que foram implementados ou existiram; • As abordagens técnicas específicas, implementações e documentações são conhecidas; • Atingir um nível n de interoperabilidade do LCIM, requer que todos os níveis abaixo (n-1, n-2, ...) sejam satisfeitos (mapeamento bottom-up da interoperabilidade entre sistemas); • Interoperar num nível n de interoperabilidade conceitual, requer a implementação dos níveis inferiores (n-1, n-2, ...). O nível n-1 é premissa do nível n (TURNITSA; TOLK, 2008). Função prescritiva: Tal qual demonstrado no famoso problema dos generais bizantinos (LAMPORT et al., 1982), nenhum componente de um sistema pode ter conhecimento perfeito dos demais componentes durante o tempo de execução. No entanto, é possível produzir um sistema com interoperabilidade adequada às finalidades pretendidas (ROBKIN et al., 2015). Neste sentido, a função prescritiva do LCIM (TOLK et al., 2007) descreve e prescreve as capacidades, propriedades, características e os níveis de interoperabilidade conceitual de um sistema ou sistema de sistemas proposto. Em outras palavras, o LCIM prescreve as abordagens e requisitos que devem ser satisfeitos para acomodar um grau alvo de representação conceitual entre sistemas, servindo como um modelo de orientação de interoperabilidade. Como prescrição, o framework fornece uma métrica para atingir um determinado nível de interoperabilidade conceitual. As características da função prescritiva do framework LCIM são: • Sistemas reais ou sistemas de sistemas não existem;

• O framework LCIM é usado para recomendar as condições necessárias e possíveis abordagens de engenharia para alcançar um certo nível de interoperabilidade; • Mapeamento top-down desde a concepção até a implementação do sistema. Níveis mais baixos são mapeados e refinados a partir de níveis mais altos; • O LCIM, quando usado no desenvolvimento de técnicas, só tem relativa estabilidade em um determinado período, uma vez que as abordagens recomendadas em sua função prescritiva estão sempre mudando e evoluindo. A função prescritiva do framework é aplicada no processo ARES para facilitar a transformação da modelagem conceitual para a implementação de sistemas, com foco nos aspectos de interoperação. Neste sentido o LCIM atua como um guia, ou lista de verificação, de como alcançar um certo nível de interoperabilidade. No contexto da pesquisa aplicada de engenharia, a combinação das duas funções permite/facilita a criação de melhores soluções para problemas de interoperação e composição. Quando não há quaisquer sistemas implementados, a prescrição define os objetivos de interoperação, analisando requisitos, premissas, constraints e assim por diante. À medida que o refinamento e a implementação evoluem gradualmente, a função descritiva passa a avaliar a interoperabilidade desse processo incremental, encontrando lacunas na interoperação entre design e implementação e objetivos. Neste caso, o ciclo de iterações se dá por prescrição– descrição–prescrição. Noutra abordagem, quando alguns sistemas ou subsistemas já existem ou foram implementados e precisam ser integrados para atingir um determinado objetivo de interoperação, o ciclo iterativo descrição–prescrição– descrição é utilizado. Em ambos os casos as funções descritiva e prescritiva do framework LCIM, quando no contexto da pesquisa aplicada de engenharia, devem ser entendidas como complementares e mutualmente dependentes.

5.1.2 Rugby

A fim de cobrir a conceitualização do processo de design e particionamento do sistema entre as diferentes disciplinas de engenharia envolvidas na implementação, o framework Rugby foi incorporado ao processo ARES. O modelo Rugby, figura 5.2, é um framework conceitual que (a) trata a modelagem e o processo de design como duas questões separadas, mas interdependentes, (b) cobre e relaciona todas as fases do design, dos requisitos a implementação, e (c) permite investigar a processo de co-design. Esse modelo representa o design em quatro dimensões: dado, tempo, computação e comunicação. Além dessas dimensões, o modelo adiciona uma dimensão ortogonal ao plano da modelagem do design para representar a manipulação do design em vários níveis de abstração.

Figura 5.2 - Modelo Rugby

Fonte: JANTSCH et al., 1999

Computação: O domínio de computação abrange as relações dos valores de entrada e saída, ou com o comportamento do sistema como é observável externamente. Comunicação: O domínio de comunicação está preocupado com as conexões e interações entre os elementos do design. Dado: O domínio de dado está relacionado aos tipos e objetos de dados que são transformados por entidades ativas de design. Tempo: O domínio de tempo diz respeito à relação temporal entre processos, atividades e comportamentos. Manipulação do design: Ortogonal aos domínios de modelagem está a manipulação do design. Em seu nível mais baixo de abstração, as entidades de design são criadas, transformadas e removidas diretamente. Já em seu nível mais alto, os métodos empregados no design são combinados em metodologias que cobrem todo o processo de design. Em cada nível do eixo de manipulação deve-se considerar os quatro domínios de modelagem de design dentro de fases específicas do projeto – representado pelos planos que cortam o modelo Rugby mostrado na figura 5.2. No framework descrito pelo modelo Rugby, é possível representar as atividades relacionadas à análise de design (Figura 5.3).

Figura 5.3 - Níveis de abstração no domínio da modelagem

Fonte: JANTSCH et al., 1999

Uma ferramenta de simulação lógica e análise temporal convencional, usada na análise do design de FPGAs (do inglês, Field Programmable Gate Array), por exemplo, requer modelos no nível de blocos lógicos no domínio de computação, no nível de tempo físico no domínio de tempo, no nível de topologia no domínio de comunicação e no nível de valores lógicos no domínio de dado. Já uma análise de viabilidade do modelo no início do ciclo de design pode ser realizada usando o nível de relações e constraints no domínio de computação, constraints temporais no domínio de tempo, constraints de tipos de dados no domínio de dado e constraints de interface e estrutura no domínio de comunicação. O framework Rugby pode ainda representar ferramentas para modelagem de desempenho e verificação formal. Uma ferramenta de verificação de deadlock em um sistema, por exemplo, pode envolver um modelo no nível de processos concorrentes no domínio de computação, no nível de causalidade no domínio de tempo, no nível de símbolos no domínio de dado e no nível de comunicação interprocessos no domínio de comunicação. Sob a ótica do processo ARES, e apesar do framework ter sido originalmente concebido para o design de sistemas ASICs (do inglês, Application Specific Integrated Circuits) mistos de hardware e software, o modelo Rugby oferece uma representação conceitual adequada para o design de sistemas complexos e suas ferramentas ao enfatizar a questão: quais conceitos fundamentais de modelagem são usados para descrever uma entidade de projeto de forma que não haja diferenciação entre visões externa e internas numa mesma descrição/abstração?. De maneira geral busca-se, nas atividades do processo ARES, o menor (mais simples) modelo capaz de representar o sistema numa determinada etapa do desenvolvimento, e cujas características sejam derivadas de primitivas de modelos num estágio anterior do ciclo de desenvolvimento de maneira evolutiva (por refinamentos sucessivos). Neste sentido os domínios de design do framework permitem a apreciação do design sob aspectos singulares que o caracterizam completamente enquanto entidade de projeto. Ademais, o modelo oferecer ainda um roteiro para a inserção de metodologias, processos e métodos particulares de

97 cada grupo de pesquisa e de cada disciplina no design do sistema, representado pelo eixo ortogonal de manipulação do design.

5.1.3 Triângulo de Couclelis

Em seu trabalho Couclelis (2010), propõe um framework ontológico baseado na noção epistemológica de informação e guiado pela noção teleológica de propósito. Desta forma, a ontologia é apenas um vértice de um triângulo de conhecimento que inclui ainda epistemologia e teleologia. Enquanto a ontologia lida com o que existe em um determinado domínio, num determinado tempo, a epistemologia está preocupada com a natureza e o escopo do conhecimento, enquanto que a teleologia está preocupada com a razão. No entendimento da autora, conciliada nos conceitos e filosofia do processo ARES, sem epistemologia, não haveria uma compreensão sistemática da natureza da correspondência entre ontologias e o domínio geral ou específico de investigação que cada uma delas representa; e, sem teleologia, não seria possível distinguir entre os resultados dos processos causais, por um lado, e os resultados das ações intencionais dos atores ou máquinas sencientes, por outro. O triângulo de Couclelis, considera a informação o pilar para a estruturação epistemológica da ontologia. A informação, enquanto noção fundamental da epistemologia, apresenta-se como escolha natural. Informação por si é um conceito relacional não absoluto que expressa uma relação intrínseca entre fonte de informação e destinatário (WILLIAMSON, 1994; HUCHARD et al., 2007). Essa característica da informação estabelece uma base para levar em consideração os interesses do usuário e, assim, forjar um elo entre ontologia e teleologia. O uso da informação como noção central traz ainda a inevitabilidade da epistemologia, visto que seu uso, em oposição ao uso de conceitos ou termos linguísticos mais diretamente associados ao mundo empírico, é precisamente que ela levanta a questão da relação entre esse mundo empírico e a ontologia em consideração. Por fim, uma vez que a informação vem em quanta, possibilita uma abordagem construtivista ao desenvolvimento de ontologias, orientando o framework.

A consideração teleológica do propósito tem seu respaldo na imprescindível necessidade de propósito no desenvolvimento de uma representação. Além do fato de que muitas das entidades empíricas representadas numa ontologia – quer seja no contexto da ciência da informação geográfica proposto pela autora, quer seja no contexto da pesquisa aplicada de engenharia abordado no processo ARES – também foram criadas ou modificadas pelo homem com propósitos específicos em mente. Por conseguinte, o propósito pode ser visto como a interface entre entidades observáveis e necessidades e desejos. O framework ontológico de Couclelis consiste em uma sequência ordenada de sete níveis hierárquicos sistematicamente relacionados: propósito, função, objetos compostos, objetos simples, classes ou similaridades, observáveis e existência. Os níveis são diferenciados pelo seu grau de riqueza semântica, variando de mínima a máxima complexidade semântica. A ideia subjacente à construção da hierarquia é a seguinte. Ciência da informação é sobre representações de entidades, não sobre as entidades em si. As representações são compostas de informações selecionadas e organizadas para algum propósito, quer seja um propósito implícito ou explícito – esta organização adequada de informações com um propósito, ou com a intenção de ser útil, partilha da definição de conhecimento de diversos autores (ZINS, 2007), e serve ao propósito da gestão do conhecimento tal como adotada no processo ARES. O objetivo da estrutura delineada no framework é apresentar em modelo sistemático de como as representações de entidades se relacionam com as informações disponíveis e com os propósitos para o quais tais representações são construídas. Nível 7 – Propósito: Esse nível descreve a interface entre o mundo das entidades e o mundo social dos agentes intencionais. Propósito determina quais funções precisam ser representadas, quais entidades distintas pertencem para formar um objeto complexo, com objetos simples são nomeados e categorizados, quais propriedades mensuráveis correspondem às entidades de interesse e como elas devem ser analisadas, que tipo de informação é relevante e, finalmente, qual estrutura espaço-temporal deve estar subjacente às representações apropriadas para o propósito em questão. Os propósitos selecionam, portanto, subconjuntos de

99 informação adequados a partir de um domínio abrangente de dados possíveis e constroem, a partir deles, os objetos de informação semanticamente apropriados para esses propósitos. Nível 6 – Função: Toda representação é projetada para funcionar cognitivamente de formas particulares, de modo a apoiar os propósitos para os quais ela foi desenvolvida. Além disso, em entidades artificiais ou naturais adaptadas para fins humanos, a função é a realização desses propósitos. Os níveis seis e sete, função e propósito, estão intimamente ligados em um relação meio-fim; no tocante em que as funções servem a um propósito. As duas perspectivas simétricas de projeto e análise são refletidas nessa relação: o projeto opera do nível sete ao seis, enquanto a análise sobe do nível seis para o sete. Nesses níveis mais altos da hierarquia, os construtos de informação coincidem com as representações das entidades no sentido comum. Cada entidade assim representada pode ter várias finalidades e funções correspondentes, e várias entidades diferentes podem ter propósitos iguais ou semelhantes. Nível 5 – Objetos compostos: Entidades compostas de partes discretas ou não homogêneas são reconhecidas como objetos únicos na extensão exigida pelas funções necessárias para atender os propósitos específicos. As propriedades que caracterizam o nível cinco ainda são bastantes abstratas, no sentido de que a inteligência necessária para distinguir e descrever objetos compostos deve ir além de quaisquer qualidades diretamente mensuráveis. Propósito e função são agora reduzidos a um papel nomeado, um atributo não essencial de objetos que não permite consultas relacionadas a mudanças funcionais e/ou associadas. Nível 4 – Objetos simples: Os objetos homogêneos conectados são categorizados e nomeados dependendo de seu papel no contexto de objetos complexos ou diretamente em sua função. Esse é nível mais baixo no qual os objetos de informação são identificados como entidades específicas do mundo real. Nível 3 – Classes: As classes podem ser definidas por propriedades únicas ou por complexos de propriedades. Nesse nível, padrões espaço-temporais e atributos de objetos são analisados e classificados com base em suas propriedades

100 mensuráveis, embora as informações disponíveis não sejam mais suficientes para identificar os objetos de informação resultantes com entidades empíricas específicas. Nível 2 – Observáveis: Objetos de informação bruta neste nível somente permitem o conhecimento qualitativo de que tipos distintos de informação relevante existem em pontos específicos no espaço-tempo. Nível 1 – Existência: Todo conteúdo semântico foi drenado do framework, exceto pela noção de que pontos específicos do espaço-tempo estão associados a informações apropriadas para os propósitos especificados no nível sete. Há apenas uma propriedade nesse nível: a existência, ou a capacidade de ter certeza de que algum tipo de informação relevante pode existir em um grânulo particular de espaço e tempo. A abordagem ontológica do triângulo de Couclelis permite a estruturação do conhecimento gerado durante a pesquisa a partir de seus propósitos específicos até os artefatos técnicos particulares de cada disciplina. Desta forma, a sequência dos modelos, da modelagem cognitiva à modelagem da implementação do sistema, define a estrutura ontológica do processo ARES e contempla a organização, retenção e apropriação do conhecimento nele gerado – num mapeamento um para um com o triângulo de Couclelis. A escolha desse framework se deu por três fatores que expressam as relações entre ontologia, epistemologia e teleologia: • Por sua consistência interna – relação ontologia-epistemologia. O mapeamento hierárquico proposto no framework permite a análise de inconsistências e lacunas internas pela apreciação e exploração dos objetos disponíveis em um nível inferior da hierarquia. • Por possibilitar a representação de objetos artificiais e mudanças intencionais dentro da mesma estrutura ontológica que objetos naturais e mudanças causais – relação ontologia-teleologia. O nível de propósito minimiza as diferenças pelo crivo de um propósito comum de interesse para o usuário. Tanto os objetos naturais quanto as mudanças causais podem ser aproveitados e modificados para cumprir um propósito, tornando-se agentes

101

de um processo intencional (por exemplo, imagem geradas por ultrassom ou energia gerada pelos ventos). • Por sua abordagem guiada pela noção teleológica de propósito – relação teleologia-epistemologia. O framework parte da identificação dos objetos de informação nos níveis superiores da hierarquia que correspondem aos propósitos de interesse. Em seguida, tendo mapeado a ontologia do domínio em questão para a estrutura hierárquica, segue-se os caminhos de ramificação relevantes descendentes do nível mais alto – de propósito para função para objetos compostos, etc. –, no qual os elementos da ontologia em consideração podem ser encontrados.

5.2 O PROCESSO ARES DESCRITO SOB A PERSPECTIVA DE SUAS ATIVIDADES

O processo ARES fundamenta-se na fluidez e suavidade das transições entre suas atividades e das transformações entre seus modelos. Na visão dos subprocessos e atividades constituintes, o processo consiste de um sequenciamento lógico de suas atividades, com artefatos presentes em seu encadeamento, porém secundários a este.

5.2.1 Modelagem cognitiva e plano de desenvolvimento preliminar

As principais atividades durante a fase inicial do processo ARES são definir claramente o domínio do problema, caracterizar o espaço solução, identificar os requisitos de negócio (ou missão) e as necessidades das partes interessadas e, ao mesmo tempo em que evita qualquer design, fornecer uma estimativa do custo e do cronograma para o desenvolvimento da pesquisa.

102

Figura 5.4 - Exploração: Modelagem cognitiva e Análise preliminar

Fonte: Autoria própria

A1.1 Identificar e mapear stakeholders e responsabilidades: Identificar, mapear e classificar toda entidade, seja grupo, organização, indivíduo, etc., que possua interesse de qualquer natureza na pesquisa e em seus resultados, ou que possa, direta ou indiretamente, afetar ou ser afetada por estes. A identificação dos stakeholders é um processo iterativo, e deve ser continuado ao longo do ciclo de vida da pesquisa, sendo o não reconhecimento de um stakeholder importante fator que pode comprometer ou mesmo impedir a realização da pesquisa.

103

No fim, para cada membro participante da pesquisa aplicada, quer seja indivíduo ou organizações, interna ou externamente ligado ao grupo de pesquisa, deve ser atribuído um conjunto de responsabilidades bem definidas e um papel específico, por exemplo, pode-se definir, no caso de uma pesquisa motivada por uma entidade externa, um Problem Owner (similar ao Product Owner do desenvolvimento de software) responsável por representar os anseios e contexto da entidade, definindo o propósito e objetivos da pesquisa. A1.2 Definir o escopo, propósito e objetivos da pesquisa: O propósito primário desta atividade é desenvolver um entendimento geral do problema e seu domínio. Deve incluir declarações de propósito, relevância e dos objetivos da pesquisa, incluindo sua transferência, justificativa, racional, definição do escopo da pesquisa e de seu “sistema de interesse” (SOI, do inglês, System Of Interest), descrições e modelos de alto nível do SOI e de suas interações com o meio e com outros sistemas. Esta atividade é sobretudo uma pesquisa exploratória, que visa a definição do domínio do problema e a caracterização de seu espaço solução (contradomínio do problema). É crítico que, nestes estudos iniciais, concepções preliminares de alto-nível (modelagem cognitiva) sejam criadas e exploradas de forma em que seja permitido identificar premissas, possíveis tecnologias, riscos e omissões no conjunto de conhecimentos técnico-científico do grupo de pesquisa para o desenvolvimento do SOI e realização da pesquisa. No contexto do processo ARES, as ações que promovem a modelagem cognitiva e a criação de seus produtos (modelos mentais e protótipo de viabilidade), devem considerar as características intrínsecas à pesquisa aplicada em engenharia (THALHEIM, 2016), a saber: • A origem de um modelo é parcialmente um produto da criatividade: Os sistemas desenvolvidos são produto de um grupo de pesquisa ou desenvolvedor e, portanto, dependem desse stakeholder. Esses sistemas devem ser compreendidos, bem explicados e usados com um propósito. • A origem de um modelo é um sistema complexo: A atenção se concentra tanto na criação de artefatos complexos quanto na conceituação do domínio do problema.

104

• O modelo satisfaz a um propósito, é compartilhável e útil: Os modelos não são desenvolvidos apenas como um resultado intermediário do processo de implementação e para satisfazer um propósito. Eles são compartilhados dentro de uma comunidade, além de darem suporte para uma melhor compreensão das origens. • A origem muda continuamente e, portanto, o modelo: O domínio e contradomínio do problema estão em constante evolução. Mudanças significativas tendem a ser aplicadas ao modelo inicial de forma que os conceitos originais se tornam irreconhecíveis. Os modelos também são usados para alterar o domínio do problema; mudanças que devem ser refletidas novamente aos modelos. • A origem sendo modelada é influenciada por constraints sociais e oportunidades: Os modelos são influenciados tanto pelos propósitos quanto pelos aspectos físicos e econômicos dos contextos em que são usados. Os modelos são ainda influenciados pelas constraints e oportunidades e pelas capacidades dos stakeholders que os criam. • Nenhuma grande teoria é capaz de soluções realistas para problemas complexos realistas: Em situações de modelagem que visão aplicações no mundo real, não existem recursos ilimitados e deve-se lidar com objetivos conflitantes de stakeholders relevantes. • O desenvolvimento de um modelo geralmente envolve uma série de ciclos de modelagem iterativa: Os artefatos que servem como modelos são desenvolvidos por meio de uma série de atividades de modelagem e são testados e revisados de forma iterativa e dependente do propósito do modelo. Os modelos mentais criados nesta atividade serão usados para determinar o que é ou não possível de ser realizado dentro do grupo de pesquisa, além de estimar, ainda que grosseiramente, custos e cronogramas da pesquisa. É ainda com base nesses modelos, que certa linguagem ou ferramenta de modelagem é selecionada para representar e modelar o sistema em sua conceptualização e concepção.

105

A1.3 Identificar constraints, riscos, normas e políticas aplicáveis à realização da pesquisa: Esta atividade consiste no levantamento e identificação de quaisquer fatores que possam impactar no sucesso do empreendimento da pesquisa. Assim sendo, deve-se identificar os riscos relacionados ao “negócio” da pesquisa, como o de não atingir um determinado objetivo, as normas aplicadas aos produtos da pesquisa e sobre a realização da pesquisa em si e as políticas e procedimentos internas e externas a instituição que imponham restrições a sua realização, como a cláusulas de propriedade intelectual na parceria entre instituto e organizações que restrinjam a divulgação científica, ou adequação de documentação específica para colaboração entre instituto e órgãos fomentadores, etc. Há um sem-fim de normas, diretrizes, publicações e guias que abordam o gerenciamento de risco e a própria definição de risco em si. Em alguns casos, faz- se obrigatório a aplicação de normas específicas, seja por órgãos reguladores ou acordos contratuais. Diante disso, e como há uma variação significativa e até mesmo contradições nos conceitos e práticas de riscos e de gerenciamento de riscos, é essencial que gestores, desenvolvedores e demais usuários do processo de gerenciamento de risco assegurem que sua compreensão e abordagem são suficientes, consistentes e apropriadas para o contexto, escopo, objetivos e propósito da pesquisa e do programa de maneira geral. A1.4 Realizara estudo de viabilidade da pesquisa: De posse dos modelos mentais engendrados na atividade A1.2, deve-se realizar um estudo de viabilidade da pesquisa, considerando, em especial, as características técnicas, a infraestrutura disponível, as estimativas de custo e prazo e as políticas envolvidas. Esta atividade, uma vez concluída, deve, ao menos, prover respostas para os seguintes questionamentos: • A pesquisa é tecnicamente factível? • Há pessoal qualificado disponível para a realização da pesquisa? • Há recurso disponível para a realização da pesquisa? Há meios de obter os recursos necessários para sua realização? • É possível realizar a pesquisa dentro do prazo pré-estabelecido e com os recursos disponíveis?

106

• Há justificativa que suporte a realização da pesquisa? Qual a relevância da pesquisa? Qual o impacto da pesquisa na comunidade acadêmica e/ou na sociedade? Com resultado desta atividade, dois artefatos mutualmente dependentes são gerados: declarações de viabilidade da pesquisa, que modificam e decidem sobre os requisitos declarativos do “negócio”, e um protótipo de viabilidade (ou modelo de engenharia), que seleciona e complementa as alternativas dos modelos mentais. Com base nos resultados do estudo de viabilidade, é tomada a decisão sobre se o esforço de desenvolvimento deve ou não ser iniciado. A1.5 Definir plano preliminar de desenvolvimento: Uma vez a pesquisa entendida como viável, as informações e artefatos gerados nas atividades anteriores são compiladas em um plano preliminar de desenvolvimento, transição e validação. O plano deve contemplar o ciclo de vida da pesquisa, seus artefatos específicos e mecanismos de controle, execução e gerenciamento, as responsabilidades dos participantes e os stakeholders da pesquisa, os recursos disponíveis, os comuns-acordos entre os diferentes stakeholders, os critérios de aceitação e validação dos resultados da pesquisa, e a estratégia de transferência da pesquisa.

5.2.2 Modelagem conceitual e validação conceitual

Neste conjunto de atividades, os cenários operacionais e os modelos do domínio e contradomínio do problema são definidos. O objetivo é desenvolver uma representação adequada da porção do mundo real que se aplica ao domínio e contradomínio do problema e seus cenários associados, o que permite destacar falhas ou vícios conceituais ainda na fase inicial de desenvolvimento. Ainda nesta fase, definem-se os objetivos do esforço de modelagem e simulação; transformados em um conjunto de requisitos que serão usados durante o desenvolvimento, testes, execução e validação do SOI.

107

Figura 5.5 - Análise: Modelagem e validação conceitual

Fonte: Autoria própria

A2.1 Criar abstração do domínio do problema: Desenvolver uma representação adequada da porção do mundo real que se aplica ao domínio e contradomínio do problema. O foco é identificar entidades relevantes dentro do domínio do problema, os possíveis relacionamentos entre as entidades identificadas e os aspectos comportamentais e funcionais de cada uma delas. Cada entidade deve possuir descritores que possibilitem identificar unicamente seus atributos, interfaces e

108 propriedades além de suas interações e comportamentos dentro do domínio específico. Deve-se ainda documentar as premissas e simplificações usadas na abstração do domínio do problema. A2.2 Identificar e analisar as relações e interfaces entre o domínio do problema e o SOI: O objetivo desta atividade é desenvolver uma especificação dos cenários operacionais 2 . Os cenários operacionais são descrições – usando ontologias e terminologias específicas do domínio do problema e/ou estendendo a ontologia de domínio específico já existente – das principais entidades do domínio do problema e suas capacidades, comportamentos e relações. Essas descrições podem tanto utilizar representações gráficas e diagramas de eventos quanto elementos textuais ou qualquer outro meio para comunicar os objetivos de um cenário específico. Independente do meio usado para expressar um cenário operacional, algumas informações são necessárias para seu uso, a saber: • O contexto do cenário, descrevendo suas premissas, constraints, considerações e estado inicial. • Os objetivos do cenário e sua relação com o domínio do problema. • A relação com outros cenários operacionais. • Descrição das entidades participantes (sistemas adjuntos, operadores, usuários, etc.) e de seus papéis no cenário. • Descrição das características, relações e comportamentos das entidades ao longo do tempo (comportamento dinâmico). • Sequência de ações ou ocorrências relevantes para os objetivos do cenário operacional. Além de descrever o domínio do problema, os cenários operacionais são necessários para especificar o que deve ou não ser representado em um ambiente de simulação específico. A2.3 Criar abstração do contradomínio do problema: Esta atividade começa como uma descrição das ações que precisam ser incluídas nos cenários

2 A definição de cenário operacional modifica àquela presente no relatório técnico STO-TR-MSG- 086-Part-II da Science and Technology Organization subsidiária da North Atlantic Treaty Organization (STO, 2015).

109 operacionais para atingir os objetivos da pesquisa; deve ainda incluir os pressupostos que compõem estas ações. O modelo conceitual fornece uma representação independente de implementação ou plataforma que serve de vetor de transformação de objetos em descrições e modelos funcionais e comportamentais do SOI para designers e desenvolvedores. Associado ao modelo conceitual do sistema de interesse, as constraints, limitações e as características “não funcionais” de sua operação e interação com as demais entidades do domínio do problema, além dos riscos técnicos associados, são compiladas em requisitos declarativos do sistema. Deve-se ainda documentar as premissas e simplificações usadas na criação do modelo conceitual. À medida que o modelo conceitual é desenvolvido, um conjunto de requisitos para o ambiente de simulação emergem; tal que sejam suficientes para orientar e especificar a criação e desenvolvimento do ambiente de simulação. Estes requisitos devem considerar as necessidades específicas de gerenciamento, controle, monitoramento, registros de dados, etc., abordando questões técnicas e programáticas em grau necessário para guiar as atividades de implementação. Ademais, tais requisitos afetam e restringem os cenários operacionais, resultando em cenários conceituais3, que fornecem uma especificação detalhada do domínio e contradomínio do problema necessária para as etapas posteriores de modelagem, simulação e desenvolvimento. O modelo conceitual do SOI e os cenários conceituais fornecem um vínculo de rastreabilidade entre os objetivos declarados e a posterior implementação do design do sistema. A2.4 Validar cenários e modelo conceituais do SOI: Existem diferentes formas de validação (ou mesmo verificação) de um artefato particular, mas, em termos gerais, estas técnicas buscam determinar o quão bom um artefato (neste caso um modelo ou cenário conceitual) representa ou se assemelha a uma ou outra referência (aqui um objetivo, requisito, premissas ou uma fonte de conhecimento validado e acreditado). O processo de validação dos cenários e modelo conceituais do SOI visa garantir que um determinado artefato (modelo conceitual ou cenário

3 A definição de cenário conceitual modifica àquela presente no relatório técnico STO-TR-MSG- 086-Part-II da Science and Technology Organization subsidiária da North Atlantic Treaty Organization (STO, 2015).

110 conceitual) contém o nível de detalhe suficiente e se representa suficientemente bem um dado aspecto ou objetivo do SOI. Em outras palavras, a “validação conceitual” é o processo de determinar se as premissas e constraints subjacentes ao modelo conceitual são corretas e se as representações/abstrações do domínio e contradomínio do problema são “razoáveis” para o propósito pretendido. É difícil estabelecer um conjunto de técnicas padrão para serem usadas em qualquer processo de validação, entretanto, entende-se que as principais técnicas aplicadas para a validação dos cenários e modelo conceituais são: a revisão contínua por especialistas (peer review), ou frente a fontes validadas e acreditadas de conhecimentos, e a construção de consenso entre os diferentes stakeholders envolvidos na especificação dos cenários e abstrações do domínio e contradomínio do problema, quanto a completude dos artefatos e o atendimento aos requisitos, objetivos e propósito da pesquisa. A2.5 Definir cenários, métricas e critérios de validação: O objetivo desta atividade é determinar a adequação de cenários conceituais para que se tornem parte do workbench de validação. Esta adequação deve considerar constraints relacionadas ao “negócio” da pesquisa – como disponibilidade, segurança, etc. –, constraints técnicas e requisitos “não funcionais” do sistema – como máximo tempo de resposta um sistema reativo, critérios de qualidade de serviço, etc. –, além de métricas e análises associadas. O workbench de validação deve ser (1) completo, abrangendo todas as entidade, relações, comportamentos e funcionalidade do SOI, (2) consistente, não apresentando contradições ou conflitos entre seus cenários constituintes, (3) correto, garantindo o atendimento aos objetivos e propósito da pesquisa, e (4) coerente, fornecendo e contemplando as informações necessárias para sua simulação e execução. A2.6 Revisar e atualizar plano de desenvolvimento: Revisar, modificar e atualizar o plano de desenvolvimento, transição e validação com as decisões e comuns- acordos estabelecidos, acrescentando ou alterando informações quanto a realização da pesquisa e refinando as estimativas feitas.

111

5.2.3 Modelagem e especificação do sistema e validação sistêmica

Com a identificação, análise e especificação de um conjunto de soluções e estratégias possíveis e a escolha de um sistema candidato, este subprocesso consolida e sintetiza o entendimento do domínio e do contradomínio do problema.

112

Figura 5.6 - Arquitetura: Modelagem, especificação e validação sistêmica

Fonte: Autoria própria

113

A3.1 Elaborar proposta para um sistema candidato: Com o objetivo de selecionar um sistema candidato para o SOI, esta atividade elenca as estratégias e soluções possíveis para o sistema de interesse. Para cada solução possível existem conjuntos de características e constraints que devem ser levantadas antes que um sistema candidato seja escolhido. Além do atendimento aos requisitos, objetos e propósito da pesquisa, questões programáticas, de know-how, de aporte de recursos ou da disponibilidade destes, do ambiente de desenvolvimento, etc., devem ser analisadas durante o julgamento de uma proposta de sistema candidato. A3.2 Definir macro-funções do sistema candidato: O sistema tratado com um modelo em “caixa preta” durante as atividades e subprocessos anteriores, é agora “aberto” e decomposto em macro-funções. Para cada macro-função deve-se então estabelecer suas interações, comportamentos, constraints e interfaces. Não há uma técnica única que permita decompor um sistema em suas partes constituintes, ou mesmo características únicas que permitam determinar se uma dada decomposição, quer seja lógica, funcional, estrutural, etc. (ou ainda uma combinação dessas), é a melhor ou mais apropriada para um dado sistema, restando à cultura e expertise existente no grupo de pesquisa e desenvolvimento o balizador desta atividade. Com a escolha de um sistema candidato e, ao passo em que se definem suas macro-funções, define-se também o ambiente de simulação, respaldado nos requisitos elencados durante a atividade A2.3 e na escolha do sistema candidato em si. A definição do ambiente de simulação começa com a seleção de ferramentas e sistemas de simulação para compor o ambiente. Esta seleção é normalmente guiada pela habilidade de uma ferramenta potencial em representar entidades, eventos ou a dinâmica do sistema candidato. Uma vez selecionados os membros do ambiente de simulação, deve-se definir de que forma se dará a interação entre eles – um acordo de interfaces e de troca de informações e dados entre as diferentes ferramentas e os diferentes sistemas de simulação. Por fim, implementa-se a infraestrutura necessária para dar suporte ao ambiente de simulação e ao processo de desenvolvimento.

114

A3.3 Realizar levantamento e análise de constraints, impactos e riscos associados ao sistema candidato: O objetivo desta atividade é ponderar sobre os riscos e constraints adicionados por um sistema candidato no atendimento aos requisitos, objetivos e propósito da pesquisa. Esta análise deve considerar os impactos que as características de um sistema candidato impõe sobre o desenvolvimento do projeto em si e sobre o programa de pesquisa no qual este projeto está inserido. A3.4 Realizar análise de viabilidade do sistema candidato: Com a proposição de um ou mais sistemas candidatos e a análise de suas constraints, impactos e riscos associados, deve-se realizar um estudo comparativo de viabilidade, a fim de determinar, dentre os sistemas candidatos, qual solução será aplicada ao SOI. Além dos aspectos técnicos, de infraestrutura, econômicos, políticos/legais e programáticos, este estudo deve considerar o aspecto operacional da solução proposta, dentre os quais, destacam-se: • O quão bem um sistema candidato “soluciona” o SOI. • O quão bem um sistema candidato faz uso das oportunidades identificadas na definição do escopo e propósito da pesquisa. • O quão bem um sistema candidato se encaixa dentro do programa de pesquisa no qual está inserido. A3.5 Identificar e catalogar soluções aplicáveis para cada macro-função: De posse do modelo em “caixa cinza” do sistema candidato, deve-se identificar e catalogar as soluções possíveis – ou um conjunto destas – que equacionam as propriedades e características de cada macro-função. A catalogação das soluções aplicáveis a uma dada macro-função deve ser realizada através da modelagem de cada uma dessas soluções em ambiente simulável, acrescida de suas características operacionais e técnicas, premissas e simplificações. A3.6 Realizar análise do impacto e características da solução particular: O objetivo desta atividade é determinar como cada solução particular no catálogo de soluções afeta o sistema e a mutualidade dos impactos e relações entre as diferentes soluções aplicáveis as diferentes macro-funções do sistema. Para cada subconjunto de soluções catalogadas que satisfazem, parcialmente ou totalmente,

115 o SOI, a análise deve considerar as características estáticas e dinâmicas da composição. A análise estática da composição contempla a estrutura semântica da composição. Esta análise verifica se a composição possui significado e se a comunicação entre seus componentes é entendida como pretendido. Para tanto deve-se garantir que os componentes compartilham o mesmo “espaço de interesse” e propósito (ou objetivo), certificando-se que não há ambiguidade pragmática e que a composição possui significado semântico – define-se um espaço de interesse como a área, parte ou domínio do sistema representado pela composição. Deve-se ainda garantir que para a troca de informações (comunicação) entre dois componentes possua significado e seja compreendida pelo destinatário, tal qual pretendida pelo remetente. A análise dinâmica da composição contempla o comportamento da composição, avaliando a consistência e coerência do comportamento. Neste ponto, analisa-se a composição e seus objetivos frente aos requisitos do sistema e aos cenários conceituais. A3.7 Selecionar conjunto de soluções para compor o sistema: Há duas etapas distintas nessa atividade. A primeira é selecionar dentre as diferentes composições para os “espaços de interesse” do sistema quais farão parte do modelo em “caixa branca” do SOI. A outra é a criação dos cenários executáveis4. Com a definição das soluções que comporão o SOI não só a troca de informações entre macro-funções deve ser definida inequivocamente, mas também o uso destas informações e dados – ou o contexto de sua aplicação – deve ser entendido e definido. Cada elemento desta composição traz ainda as características específicas de cada solução para o sistema em si. Estas características impõem suas constraints, premissas e características não-funcionais e devem ser conhecidas pela equipe de desenvolvimento. Um cenário executável especifica e fornece todas as informações necessárias para a preparação, inicialização e execução de um cenário conceitual

4 A definição de cenário executável modifica àquela presente no relatório técnico STO-TR-MSG- 086-Part-II da Science and Technology Organization subsidiária da North Atlantic Treaty Organization (STO, 2015).

116 específico em um ou mais membros do ambiente de simulação. Desta forma, um modelo executável especifica não só quais membros específicos do ambiente de simulação com quais configurações específicas farão parte de uma execução específica, mas também qual subespaço do cenário conceitual e do SOI com quais propriedades/características será simulado. No final do processo a totalidade dos cenários conceituais deve ser contemplada no conjunto dos cenários executáveis. A3.8 Validar sistema-solução: A validação do sistema-solução ou validação sistêmica da solução proposta confronta as características do modelo em “caixa branca” do SOI e de sua simulação em cenários executáveis frente ao workbench de validação. Esta validação pode ser descrita sinteticamente como a avaliação da solução proposta pela substituição do sistema em “caixa preta”, presente nos cenários conceituais que compõem o workbenck, pelo modelo em “caixa branca” dessa solução e pela substituição dos cenários conceituais por seus cenários executáveis correspondentes, considerando os critérios de validação e as características não-funcionais do SOI. A3.9 Definir métricas, análises e critérios de verificação e interoperabilidade entre macro-funções: O objetivo desta atividade é determinar as interações possíveis entre duas macro-funções particulares, especificando-as em cenários de interoperabilidade. Para cada cenário de interoperabilidade um conjunto de métricas e critérios associados deve ser definido de forma a permitir uma análise objetiva dos usos e das trocas de informações por e entre diferentes macro-funções e das características de cada solução particular dos modelos em “caixa branca” aplicáveis. A3.10 Revisar e atualizar plano de desenvolvimento: Revisar, modificar e atualizar o plano de desenvolvimento, transição e validação com as decisões e comuns-acordos estabelecidos, acrescentando ou alterando informações quanto a realização da pesquisa e refinando as estimativas feitas.

117

5.2.4 Design da arquitetura do sistema e particionamento

Este conjunto de atividades representa a ponte entre especificação e implementação, concentrando-se no sistema-solução, ou imagem do problema, e o acionador do mecanismo incremental/evolutivo de desenvolvimento. A partir do levantamento de um repertório tecnológico e técnico aplicável ao sistema-solução, definem-se o conjunto de tecnologias (subconjunto do repertório) e as premissas e regras/requisitos associados à arquitetura empregada no sistema-solução, especificando a infraestrutura da arquitetura proposta, suas características e constraints, e as interfaces entre as diferentes tecnologias. Por fim cada macro- função é aportada na arquitetura, em uma ou mais tecnologias disponíveis, e verifica-se sua interoperabilidade com as macro-funções adjacentes.

118

Figura 5.7 - Arquitetura: Design da arquitetura e Particionamento

Fonte: Autoria própria

119

A4.1 Identificar e catalogar tecnologias aplicáveis ao sistema-solução: Esta atividade inicia o subprocesso de design no nível de sistema (system level design), que tem por objetivo implementar/transladar a especificação do sistema numa arquitetura alvo, refinando esta especificação em um conjunto de especificações particulares das tecnologias e arquitetura definidas. Desta forma a criação do repertório tecnológico é dependente da estratégia de design adotada na pesquisa. Considerando as três principais abordagens para o design no nível de sistema (CAI, 2004) – síntese de sistema (ou co-design de hardware e software), design baseado em plataformas e design basedo em componentes – entende-se: • Síntese de sistema (CHOI, 2012): Pode-se definir esta abordagem como o design cooperativo de hardware (componentes físicos) e software para atingir os objetivos do sistema (requisitos funcionais e não-funcionais), explorando a sinergia entre estes. Esta é uma estratégia top-down que adiciona gradualmente detalhes de arquitetura e design sobre as especificações e comportamentos do sistema. De forma semelhante deve- se construir o repertório tecnológico, identificando e catalogando a cada adição as premissas de arquitetura e as tecnologias aplicáveis, suas características e decisões relacionadas. • Design baseado em plataformas (KEUTZER et al., 2000): Em vez de gerar a arquitetura através de um processo top-down de refinamentos e adições como no co-design de hardware e software, o design baseado em plataformas mapeia os requisitos e comportamentos do sistema para uma arquitetura predefinida, ou plataforma, numa abordagem meet-in-the-middle. Desta forma o repertório tecnológico deve abranger a tecnologia presente na plataforma em si e possíveis modificações, atualizações ou adições à esta. • Design baseado em componentes (MAHMOOD et al., 2007): Nascida na engenharia de software, o design baseado em componentes é uma estratégia bottom-up. Nesta abordagem a arquitetura surge do encadeamento e agrupamento de componentes heterogêneos existentes, através da inserção de invólucros entre e estes componentes. O repertório

120

tecnológico é então o conjunto das características e tecnologias de cada componente e dos invólucros criados. A4.2 Realizar levantamento e análise de constraints, impactos e riscos associados à tecnologia: Nesta atividade deve-se ponderar sobre os riscos, impactos e constraints adicionados por uma tecnologia ou técnica particular no atendimento aos requisitos do sistema e, consequentemente, aos objetivos e propósito da pesquisa e do programa. Sendo assim, esta análise deve considerar não só os impactos que uma dada tecnologia ou premissa de arquitetura tem sobre o desenvolvimento e implementação do sistema, mas também sobre os possíveis desdobramentos deste sistema dentro do programa de pesquisa no qual está inserido. A4.3 Definir arquitetura do sistema-solução: Do ponto de vista do processo ARES, a arquitetura do sistema-solução é a infraestrutura que permite sua realização associada a uma filosofia de design, um conjunto de regras/requisitos que restringem e guiam o design e implementação desse sistema. Deste entendimento, o objetivo desta atividade é definir, a partir do repertório tecnológico, o conjunto de tecnologias que comporá o sistema-solução, as regras de associação e de interfaces dessas tecnologias, a infraestrutura aportada no sistema e em cada tecnologia e os requisitos para o design e implementação, ou requisitos de arquitetura. A4.4 Definir particionamento das macro-funções (Co-arquitetura): Da definição da arquitetura, ou de uma arquitetura candidata, define-se o particionamento das macro-funções. O processo de particionamento tem por base as capacidades de uma ou mais disciplinas (eletrônica analógica, eletrônica digital, software e firmware, mecânica, etc.) no cumprimento das premissas e requisitos de arquitetura no aporte de uma macro-função. Cabe ressaltar que, nesta atividade, deve-se considerar as macro-funções como elementos integrantes do sistema e interdependentes entre si, deve-se considerar suas interações com as demais macro-funções e como estas interações serão resolvidas dentro da arquitetura proposta. Deve-se considerar ainda o impacto que esta proposta de arquitetura e as tecnologias empregas no

121 particionamento de uma macro-função exercem sobre ela e o impacto que esta exerce sobre as tecnologias e arquitetura. Desta forma não se exclui, nesta atividade, a adição de elementos ao sistema a fim de estabelecer o “casamento de impedância” entre as macro-funções e as tecnologias. A4.5 Aportar macro-funções nas tecnologias designadas: Com o particionamento e distribuição das macro-funções nas tecnologias e arquitetura propostas para o sistema-solução, cada macro-função é modela segundo as premissas e requisitos de arquitetura para as tecnologias nas quais será aportada e implementada. Noutras palavras, tem-se um conjunto de modelos, ou mesmo um modelo único, que representa o sistema-solução sobre uma abstração da arquitetura proposta. A4.6 Verificar interoperabilidade da estratégia de arquitetura: Verificar a estratégia de arquitetura é verificar as interações entre as macro-funções aportadas nesta arquitetura confrontando-as com a interoperabilidade do modelo em “caixa branca” do sistema-solução. Destarte, para cada macro-função presente num cenário de interoperabilidade específico: substitui-se essa macro-função por seu símile no modelo de arquitetura; executa-se, em ambiente simulável, o cenário de interoperabilidade correspondente, e; confrontam-se os resultados dessa simulação com as métricas e critérios presentes no workbench de verificação e interoperabilidade. A4.7 Definir plano de design e implementação: Cada disciplina envolvida no desenvolvimento do sistema possui seu próprio ciclo de desenvolvimento, por exemplo, as etapas e atividades e os recursos destinados à elaboração e implementação de uma interface homem-máquina diferem completamente daqueles empregados no design, fabricação e montagem de placas de circuitos impressos. Como consequência, o design e implementação do sistema deve considerar as características particulares de cada disciplina e do sistema-solução, bem como da equipe envolvida e da infraestrutura disponível para o desenvolvimento, terceiros e demais envolvidos, segmentando o desenvolvimento em etapas, alocando os recursos necessários e determinando o prazo e a sequência para a execução de cada uma dessas.

122

Este planejamento é similar àquele proposto no processo FDD (PALMER; FELSING, 2002), entretanto a segmentação do desenvolvimento não se dá por funcionalidades, mas pela agregação de macro-funções e disciplinas. Sendo assim, para cada grupo de desenvolvedores numa disciplina, atribui-se um conjunto de macro-funções – numa sequência de desenvolvimento específica – aportadas nas tecnologias de domínio dessa disciplina ou grupo particular, considerando o tamanho da equipe, o tempo e os recursos disponíveis para o desenvolvimento. A4.8 Revisar e atualizar plano de desenvolvimento: Revisar, modificar e atualizar o plano de desenvolvimento, transição e validação com as decisões e comuns- acordos estabelecidos, acrescentando ou alterando informações quanto a realização da pesquisa e refinando as estimativas feitas.

5.2.5 Encapsulamento e validação do design

As atividades neste subprocesso iniciam o mecanismo incremental/evolutivo e compreendem a primeira etapa da implementação com a criação de modelos encapsulados e módulos de implementação. O principal objetivo deste conjunto de atividades é propiciar uma transição rastreável e uniforme entre modelagem e implementação, permitindo a explícita correlação entre seus artefatos numa abordagem equipolente ao design-by-contract™ – Eiffel Software – (CROCKER, 2004), onde os modelos definem, e são em si mesmos, o “contrato de implementação”, especificando interfaces, tipos, pré- e pós-condições, constantes, etc. Há duas atividades distintas e complementares de modelagem nesta etapa: a modelagem da abstração de tecnologia e arquitetura do sistema – precedida pela especificação das interfaces, tipos, dados e mensagens trocados entre as macro- funções e as tecnologias – e o encapsulamento dos módulos de implementação, que gera o modelo encapsulado do sistema. A amálgama dessas atividades de modelagem emula e cria uma virtualização da implementação do sistema em ambiente simulável que: estabelece o contrato de implementação, suas obrigações

123 e condições, e; garante o predicado correto por construção (HALL; CHAPMAN, 2002) ao sistema.

124

Figura 5.8 - Design: Encapsulamento e validação do design

Fonte: Autoria própria

125

A5.1 Definir e especificar interfaces, tipos, dados e mensagens entre as macro-funções e as tecnologias: Na definição da arquitetura do sistema e no particionamento das macro-funções, as mensagens e dados são vinculadas por canais “ideais”, por meio dos quais as informações são enviadas e recebidas conforme necessário, elencando possíveis conflitos na solicitação de uso de recursos, mas sem ajuizar sua compatibilidade ou viabilidade num design possível. À medida que o design é refinado, e os módulos de implementação são encapsulados, são especificados os recursos de comunicação, os protocolos de controle, as políticas de compartilhamento das unidades, o fluxo e os pacotes de dados e configurações, etc. Uma transação ou troca de mensagens entre duas tecnologias pode ou não permitir interrupção, pode ou não requisitar um gatilho externo, ou que um valor de entrada numa porta seja persistente, etc. Desta forma, nesta atividade, resolve-se ainda a necessidade de mecanismos auxiliares para a realização das interfaces. Por exemplo, se uma dada tecnologia, que não suporta leituras bloqueantes, estiver conectada a uma outra que requer uma operação de leitura bloqueante, o canal que conecta essas tecnologias deve fornecer serviços adequados para habilitar essa comunicação (e.g., mecanismos de fila). Ao final de cada ciclo desta atividade um conjunto de especificações, propriedades, atributos, requisitos e constraints complementam os requisitos declarativos de design e documentam a rastreabilidade das decisões de engenharia tomada. A5.2 Segmentar o sistema em módulos de implementação (Co-design): Nesta atividade o esforço de design e implementação do sistema é segmentado em tarefas menores que considera um subconjunto do particionamento por vez, de forma semelhante ao proposto na criação dos pacotes de trabalho no processo FDD (PALMER; FELSING, 2002). A cada iteração, as características e dependências das disciplinas envolvidas no design e implementação do módulo, os recursos disponíveis e alocados para o seu desenvolvimento, quer seja tempo disponível, time alocado, etc., quer seja a contratação de serviços de terceiros ou o suporte de

126 outros times, e as características de cada um de seus elementos constituintes, devem ser ponderados na determinação dos módulos de implementação. A5.3 Criar modelo de abstração de tecnologia: De posse das características e constraints das tecnologias empregadas e dos requisitos e modelos da arquitetura e com a especificação das interfaces, tipos, dados e mensagens entre tecnologias, modela-se, em ambiente simulável, o comportamento e a estrutura da estratégia de design para a arquitetura. Concordante com o princípio de interface layering introduzido na norma de documentação comportamental de interfaces no nível de sistema da Virtual Socket Interface Alliance (SYSTEM-LEVEL DESIGN DEVELOPMENT WORKING GROUP, 2000). A sequência de atividades A4.3, A5.1 e A5.3 estabelecem uma hierarquia de abstração (refinamento contínuo) sobre as interfaces e arquitetura do sistema. Por exemplo, uma interface definida na arquitetura por operações bloqueantes de leitura e escrita, pode ser especificada como ações de leitura e escrita dependente de ações assíncronas de solicitação e reconhecimento (request/acknowledge), e posteriormente, em um nível mais próximo da implementação, essas ações assíncronas de solicitação e reconhecimento poderiam ser vinculadas a um sinal síncrono – sinal de relógio ou clock – disponibilizado e distribuído por um elemento de hardware. A5.4 Realizar análise dos constraints e impactos do design sobre cada módulo de implementação: O objetivo desta atividade é determinar como cada módulo de implementação, e o sistema em si, é afetado pelas escolhas e estratégias do design. As análises a serem realizadas nessa etapa são dependentes das características e requisitos do sistema, podendo abranger análises de energia e consumo, análises temporais, etc., e podem ou não serem associadas a modelos específicos. E mesmo as análises realizadas podem ser mais ou menos extensivas ou rigorosas, dependendo dos objetivos e propósito da pesquisa. Desta forma, deve-se justificar e especificar cada análise executada sobre o design. A5.5 Definir métricas, análises e critérios de verificação unitária dos módulos de implementação: O objetivo desta atividade é determinar os meios para verificar que um design desenvolvido sobre uma ou mais tecnologias atenderá aos requisitos

127 não-funcionais e constraints do sistema, de forma a permitir uma análise objetiva sobre a estratégia de design dos módulos de implementação e da integração destes ao sistema e entre si. Tal como a arquitetura e o design em si, o conjunto de análises, métricas e critérios definido aqui é depende das tecnologias empregadas. Espera-se, entretanto, que o workbench de verificação unitária e integração englobe, pelo menos, análises temporais e de integridade dos dados e sinais. A5.6 Revisar e atualizar o plano de design e implementação: Revisar, modificar e atualizar o plano de design e implementação, incorporando ao plano as decisões técnicas e gerencias pertinentes ao andamento de suas atividades e etapas. A5.7 Revisar e atualizar o plano de desenvolvimento: Revisar, modificar e atualizar o plano de desenvolvimento, transição e validação com as decisões e comuns-acordos estabelecidos, acrescentando ou alterando informações quanto a realização da pesquisa e refinando as estimativas feitas. A5.8 Encapsular módulos de implementação: Nesta atividade adicionam-se as dependências entre a realização de um módulo de implementação e as tecnologias que o abarcam. Seguindo as regras e o modelo de arquitetura (particionamento) e os requisitos de design e de posse dos modelos das abstrações de tecnologias, definem-se os contornos da realização de um módulo de implementação e modela- se o design resultante, encapsulando-se cada elemento do módulo em seus contornos e constraints de realização e design. Desta forma, se num sistema definem-se, por exemplo, a supressão de componentes de frequência de um sinal (filtro) como uma macro-função, ou etapa de processamento necessária para sua realização, e a eletrônica analógica como tecnologia empregada em sua realização, aportá-la na tecnologia é fazer com que as propriedades e características para sua realização emerjam. Já seu encapsulamento na tecnologia é definir sua topologia, tendo como modelo encapsulado resultante o circuito esquemático correspondente. A5.9 Verificar módulos de implementação: A verificação unitária dos módulos de implementação deve confrontar os modelos encapsulados dos módulos aos critérios e análises definidas sobre a abstração da tecnologia. Esta verificação não se trata da caracterização individual de cada elemento presente no módulo de

128 implementação, mas no atendimento aos critérios que garantem a integração e operação do módulo ao sistema pretendido. A5.10 Verificar interoperabilidade do design: Para cada macro-função presente num cenário de interoperabilidade específico, verifica-se, substituindo a macro- função pelos modelos encapsulados que a compõe, se os resultados obtidos são compatíveis aos critérios e métricas presentes no workbench de verificação e interoeperabilidade. A5.11 Validar design: A validação do design avalia o quão bom o design, representado pelos modelos encapsulados, apresenta-se em manter os objetivos e características esperadas para o sistema. Essa validação é tal qual a validação sistêmica e se dá pela substituição do modelo de design nos cenários executáveis correspondentes.

5.2.6 Implementação, verificação e validação da implementação e validação e transferência da pesquisa

Há três macro-etapas distintas neste subprocesso. No primeiro conjunto de atividades ocorre a transição entre o esforço de modelagem e a implementação do sistema. O objetivo desta primeira etapa é garantir rastreabilidade e fluidez entre abstração e realização. No segundo, os resultados da pesquisa são publicados e divulgados, contemplando os objetivos acadêmicos propostos. Na última macro- etapa, as técnicas e conhecimentos específicos gerados durante a pesquisa são reunidos para integrar o acervo de transferência de conhecimento da pesquisa.

129

Figura 5.9 - Implementação e teste: Implementação, verificação e validação de implementação e de pesquisa

Fonte: Autoria própria

130

A6.1 Criar modelos de implementação: Geralmente vinculado a uma ferramenta altamente especializada, um modelo de implementação é a representação de mais baixo grau de abstração para um componente. Um programa em linguagem C ou em outra linguagem de programação, por exemplo, é um modelo de implementação, visto que em última instância um processador só computa um conjunto de instruções binárias definidas em seu opcode, ou código de operação, e que os programas escritos nessas linguagens podem ser compilados e transcritos para este conjunto de instruções. Sendo assim, criar um modelo de implementação de um componente do sistema é criar uma representação que possa ser executada/implementada automaticamente ou em relação de 1:1 na tecnologia alvo no mundo real. Desenhos assistidos por computador (CAD), layouts de circuitos eletrônicos, códigos fontes, etc., são exemplos de modelos de implementação. A6.2 Verificar modelos de implementação: Esta verificação se dá sobre o conjunto de modelos de implementação que compõem um módulo de implementação particular. Sendo assim não se trata da verificação e caracterização de um elemento separadamente, mas da análise da associação dos elementos constituintes de um módulo de implementação utilizando as métricas e os critérios presentes no workbench de verificação unitária e integração. É esperado que esta atividade gere requisitos de testes para a implementação de cada elemento. Porém esta atividade é interna a uma disciplina e atende a seus próprios critérios e métricas. A6.3 Implementar modelo de implementação: Esta atividade se trata da realização do sistema no mundo real. Compete a esta atividade, a confecção e montagem das placas de circuito impresso, a usinagem/construção/aquisição dos componentes mecânicos, a compilação e carregamento do código fonte no processador próprio, etc., e a integração desses no sistema. A6.4 Verificar implementação (Co-simulação): Pari passu com as atividades de verificação unitária anteriores, esta verificação não se trata da caracterização e teste de cada elemento isoladamente, mas da análise dos conjuntos coerentes representados pelos módulos de implementação frente ao workbench de verificação unitária e integração.

131

Uma vez que se trata da implementação física do módulo de implementação, a simulação direta, possível nas etapas de verificação anteriores, é inviável. Deve- se, então, considerar o emprego de técnicas de co-simulação, como functional mock-up interface (MODELICA ASSOCIATION, 2012), ou mesmo implementações parciais do workbench e estratégias hardware-in-the-loop, na realização dessa atividade. A6.5 Verificar interoperabilidade e integração da implementação: Com a implementação dos módulos de implementação e das macro-funções, deve-se comparar a execução destas em emulações dos cenários de interoperabilidade aos resultados obtidos na verificação dos modelos encapsulados considerando os critérios e métricas definidos no workbench de verificação e interoperabilidade. A6.6 Implementar workbench de validação: O objetivo desta atividade é criar um setup de validação, ou setup experimental, que realize os cenários de validação no mundo real. Cabe notar que esta não é necessariamente uma implementação um para um; não se espera que seja possível implementar cada um dos cenários de validação, mas os objetivos destes. A6.7 Validar implementação do sistema-solução: A validação da implementação é a execução do sistema no setup de validação, avaliando o atendimento aos objetivos da pesquisa e aqueles esperados para o sistema em si. Essa atividade representa o melhor esforço que um núcleo de pesquisa pode empregar na validação de seu trabalho, mas cabe a comunidade, a academia, a validação do sistema, dos resultados alcançados e, em última instância, da pesquisa. A7.1 Divulgar/Lançar sistema e documentação necessária para validação externa: Nesta atividade os resultados alcançados na pesquisa são compilados em documentação acadêmica (artigos, teses, dissertações, etc.), e postos à avaliação da academia, única com legitimidade para julgar e validar uma pesquisa. Cabe lembrar que, tratando-se de pesquisa aplicada em engenharia, o know-how adquirido deve ser objeto de publicação e divulgação acadêmica. A7.2 Realizar a transferência da pesquisa: No tocante à transferência da pesquisa, há dois processos distintos. O primeiro diz respeito a transferência interna, onde os conhecimentos, técnicas, know-how, etc., são reunidos e

132 compilados num acervo de boas práticas, diretrizes, guias/guidelines, etc., e juntados aos artefatos e modelos engendrados na pesquisa, à sua documentação acadêmica e especificações (datasheets) do sistema-solução. O outro trata da transferência externa do conhecimento. Aqui, espera-se um comum acordo sobre a transferência, com artefatos e processos bem definidos para que esta ocorra da maneira intentada pelas partes.

5.3 O PROCESSO ARES DESCRITO SOB A PERSPECTIVA DO ESFORÇO DE MODELAGEM

O desenvolvimento de modelos apresenta muitos desafios. O processo de modelagem em si altera o domínio de aplicação do modelo e a compreensão sobre o que é modelado em si (origem). Não sendo, portanto, redutível a regras do tipo evento-condição-ação. Modelar não é sobre desenvolver modelos, mas desenvolver os modelos certos – desenvolvendo modelos no momento certo, com o contexto e background certos e para o propósito certo –. As definições dos conceitos de modelo e de modelagem (e consequentemente do ato de modelar) adotadas no processo ARES apropriam-se da acepção destes termos segundo Thalheim (2016, 2017). Segundo o autor, a modelagem pode ser entendida como uma técnica ou como uma tecnologia distinguida entre ciência e engenharia. De maneira geral, a ciência é a tentativa sistemática de entender e interpretar o mundo, por exemplo, usando as leis da gravitação de Newton, pode-se comparar suas implicações a alguma realidade observável para avaliar se e onde elas se encaixam. As premissas e abstrações assumidas na modelagem, uma forma de lidar com a infinita complexidade do fenômeno observado, restringem a aplicação de seus produtos a um certo limite que deve ser explicitamente conhecido e compreendido. Retomando o exemplo das leis da gravitação de Newton, estas apenas se mantêm perto da superfície e para objetos de um certo tamanho. A adoção de uma abstração no processo de modelagem sempre implica que certas propriedades são perdidas enquanto as propriedades relevantes, com relação ao propósito do modelo, são

133 capturadas com um grau de detalhes suficiente para cumprir o propósito do modelo. O trabalho Bull, figura 5.10, de Pablo Picasso (1945), exemplifica de forma brilhante o uso de simplificações/abstrações sucessivas na análise da forma e captura da presença essencial do objeto.

Figura 5.10 - Extração de propriedades essenciais por simplificações/abstrações sucessivas

Fonte: PICASSO, 1945

134

Engenharia por sua vez é o estudo sistemático de técnicas para criar/realizar e fazer coisas. Na engenharia, a modelagem aborda todas as preocupações (concerns) relevantes, dividindo um sistema complexo em tantos modelos quanto forem necessários, de tal forma que elas se tornem compreensíveis, analisáveis e, finalmente, possam ser construídas. Sendo assim, reside no fenômeno a diferença fundamental da modelagem enquanto ciência e engenharia, uma vez que na engenharia, o fenômeno não necessariamente existe no momento em que a modelagem é iniciada, visto que o objeto é geralmente construir o fenômeno (e.g., sistema, mecanismo, processo, software, etc.) a partir do modelo, que funciona como um guia ou mapa para a realização (BRUEL et al., 2015). Ainda na visão de Thalheim, modelagem pode ser entendida ao mesmo tempo como uma arte, posto tratar-se de um processo altamente criativo que requer perícia no planejamento, criação e/ou execução, com uma visão profunda do contexto, bem como habilidades e aptidões específicas, experiência e engenhosidade; concomitante ao julgamento e seleção de diferentes alternativas e visões, influenciado pela variedade dos pontos de vista das diferentes partes interessadas (stakeholders) – na figura 5.11 diferentes representações do problema das pontes de Königsberg apresentam diferentes pontos de vista sobre o problema em si. Por fim, modelagem é ainda uma cultura, apoiada por máximas pragmáticas e de colaboração, por hábitos e senso comum dentro de um coletivo de pensamento, por postulados, suposições, valores, visões e princípios herdados das disciplinas nesse coletivo. Além disso, a cultura da modelagem incorpora invariância de propósitos, construções ou propriedades de arquitetura para modelos (monotonicidade, incrementalidade, consistência de aplicação, etc.), abordagens para manipular propriedades assumidas implicitamente e uma variedade de princípios (abstração, agrupamento, separação e integração de concerns, etc.).

135

Figura 5.11 - Representação de domínio específico das pontes de Königsberg: a. Vista aérea de Königsberg; b. Modelo topográfico de Euler; c. Modelo topográfico de König; e, d. Representação das pontes de Königsberg em grafo não dirigido

Fonte: a. MERIN, 1952; b. EULER, 1736; c. KÖNIG, 1905; d. KÖNIG, 1936

Já nas definições de modelo apresentadas pelo autor, uma dualidade conceitual interpreta o modelo enquanto artefato e instrumento. Um modelo é um artefato construído de certa maneira e preparado para sua utilização de acordo com o propósito em consideração, como a construção de um sistema, verificação, otimização, etc. (THALHEIM; TROPMANN-FRICK, 2016). Nesta concepção, um modelo é um artefato bem formado, adequado e confiável que representa uma ou mais origens. A criação para fins práticos significa que o principal alvo do desenvolvimento de um modelo é sua aplicação em algum cenário de utilização, ou seja, há algum motivo, alguma meta ou propósito para seu uso e alguma função que o modelo deve desempenhar no cenário. Consequentemente, um modelo é um instrumento em seu cenário de utilização com um dado espectro de uso. Sob esta ótica, um modelo serve a um propósito, de sorte que os critérios de boa formação, adequação e confiabilidade devem ser comumente aceitos por sua comunidade de prática dentro de algum contexto e corresponder às funções que o modelo preenche em seus cenários de utilização, só podendo ser dito útil com o conhecimento deste propósito e de seus objetivos.

5.3.1 O propósito de um modelo

Das dimensões principais – propósito, resultado de mapeamento, linguagem e valor – e das dimensões de contexto (THALHEIM, 2016), é a dimensão de

136 propósito de um modelo (com suas as intenções, objetivos e metas), que governa o modelo, as atividades e o esforço de modelagem, o processo de desenvolvimento e o processo de aplicação. Modelos são desenvolvidos com diferentes objetivos, com diferentes escopos, dentro de diferentes contextos, com diferentes granularidades, com diferentes origens e backgrounds e com diferentes formas de realização. O propósito da modelagem é descrito pelo escopo do modelo, pela comunidade de usuário, pelas tarefas que o modelo deve dar suporte, pelas finalidades principais e secundárias satisfeitas pelo modelo e pelo valor e benefícios obtidos pelo e através do modelo para uma dada comunidade de usuários. Enquanto que as finalidades e objetivos de um modelo são baseados no impacto do modelo; circunscritos pelas relações entre usuários e os papéis que estão desempenhando. À vista disso, é fundamental, para a correta aplicação de um modelo, tonar explícitas algumas propriedades da dimensão de propósito de um dado modelo: • Qual o impacto do modelo em relação a solução para um problema? • Quais os insights/introspecções sobre as propriedades da origem? Como o mundo é ou deve ser estruturado? Como a funcionalidade deve ser descrita? • Quais as restrições sobre a aplicabilidade e validade do modelo? Qual o intervalo de vaidade e vida útil do modelo? • Quais as razões que suportam o valor do modelo? Sua corretude, generalidade, utilidade, compreensibilidade, etc. • Quais as capacidades do modelo? Como o modelo auxilia na compreensão da origem? Como suporta a verificação de hipóteses dentro de um escopo limitado? Como o modelo suporta a construção de artefatos técnicos?

5.3.2 Transformação de modelo

Uma transformação de modelo, noção fulcral nas metodologias e processos baseados (model-based), guiados (model-driven) ou centrados (model-centric) em modelos, se caracteriza pela aplicação de um conjunto de regras de transformação

137 sobre um ou mais modelos fonte de modo a produzir um ou mais modelos alvo (SENDALL; KOZACZYNSKI, 2003). Alguns de seus conceitos comuns, emergentes dos diversos estudos em transformações de modelos (CZARNECKI; HELSEN, 2006; MENS; VAN GORP, 2006; LÚCIO et al., 2016), foram incluídos no processo ARES, a fim de conferir coerência e rastreabilidade ao processo. Transformações endógenas e exógenas: Modelos fonte e alvo podem ser expressos por meio de um mesmo meta-modelo ou por meta-modelos diferentes. Transformações endógenas produzem modelos alvo expressos no mesmo meta- modelo dos modelos fonte. Por sua vez, transformações exógenas produzem modelos alvo expressos em um meta-modelo diferente daquele dos modelos fonte. Transformações horizontais e verticais: Modelos fonte e alvo podem existir em um mesmo nível de abstração ou existir em níveis de abstração diferentes. Transformações horizontais produzem modelos alvo no mesmo nível de abstração dos modelos fonte. Enquanto que transformações que produzem modelos alvo em nível de abstração diferente daquele dos modelos fonte são chamadas de transformações verticais. Estes conceitos, além da relação dos modelos fonte e alvo de uma transformação, devem ser explícitos em cada operação de transformação de modelo, garantindo a rastreabilidade entre os modelos alvo e modelos fonte e os posicionando entre os artefatos e modelos gerados durante a execução do processo ARES. Outrossim, para conferir lógica às transformações, o objetivo da transformação deve ser explícito em cada operação de transformação de modelo. Lúcio et al. (2016) propõem um catálogo de intenções de transformação que identifica e categoriza as principais intenções listadas na literatura em nove diferentes grupos: Refinamento, Abstração, Definição semântica, Tradução de linguagem, Satisfação de constraint, Análise, Edição, Visualização de modelos e Composição de modelos. Por fim a operação de transformação deve ser explícita. Entende-se, porém, que nem sempre é possível conhecer ou especificar explicitamente o conjunto de regras de transformação, como no caso do uso de ferramentas de geração automática de código, o que compromete a completude, coerência e especificidade

138 da operação de transformação. A fim de superar esse problema, propõe-se tornar explícito as propriedades específicas dos modelos fontes transferidas/mantidas nos modelos alvos, numa abordagem similar àquela proposta por Jarus et al. (2016).

5.3.3 Validação de modelos

Validação tem sido uns dos problemas não resolvidos da modelagem de sistemas (MOHAPATRA, 1987 apud MARTIS, 2006), e apesar de todo esforço empregado na tentativa de definir o conceito de validação de modelos (MARTIS, 2006; LEMKE; LATUSZYNSKA, 2014; SARGENT et al., 2000), é o entendimento de Shreckengost (1985), que melhor se aplica à realidade da modelagem e simulação, no contexto do processo ARES. Segundo o autor, em um senso estrito, não há modelo totalmente válido, visto que todo e qualquer modelo é menos que o objeto real, ou sistema, modelado. Desta forma, descritores como útil/profícuo, esclarecedor, ou que transmite confiança, são mais adequados aos modelos do que o descritor válido (GREENBERGER et al., 1976) – visão resumida na definição do conceito de validade de Coyle e Exelby (2000), de que não existe validade absoluta, apenas um grau de confiança que se torna maior à medida que mais e mais testes são realizados. Destarte, adota-se no processo ARES os critérios de validade gerencial de modelos propostos por Schellenberger (1974), para avaliar a validade dos modelos – ou alternativamente para a acreditação dos modelos – gerados em seu ciclo de desenvolvimento.

5.3.3.1 Critérios de validade gerencial de modelos

Os critérios de validade gerencial de modelos, ou critérios de Schellenberger, reconhece três tipos distintos de validade: a validade técnica; a validade operacional; e a validade dinâmica. A validade técnica requer a identificação de todas as divergências nos pressupostos e premissas do modelo a partir da realidade percebida, bem como a identificação da validade dos dados usados no modelo. A validade operacional lida com a questão da importância/impacto das divergências

139 que são identificadas sob a validade técnica. Por fim, a validade dinâmica assegura que o modelo continuará a ser operacionalmente válido. Validade técnica: A validade técnica refere-se a um conjunto razoavelmente identificável de critérios contra os quais qualquer aplicação de análise gerencial pode ser comparada. Os quatros principais componentes da validade técnica são: (1) validade do modelo; (2) validade dos dados, distinguida entre dados brutos (raw data) e dados estruturados; (3) validade lógica; e (4) validade preditiva. 1. Validade do modelo: Refere-se à correspondência deste com o mundo real. A validade do modelo deve ser julgada pela comparação de suas premissas e pressupostos com o mundo real que modela. Como consequência, o ponto de partida para julgar a validade técnica é identificar as premissas e pressupostos do modelo. a. Premissas matemáticas. Essas premissas dizem respeito a natureza matemática do modelo. A exemplo da natureza linear de modelos de programação linear, ou a premissa de que as relações entre variáveis são contínuas num intervalo de interesse. b. Premissas de conteúdo. Esse tipo de premissa lida com o conteúdo dos termos e das variáveis dentro dos termos. Em outras palavras, as premissas de conteúdo lidam com as simplificações e escopo adotados no modelo. c. Premissas causais. Idealmente um modelo contém apenas relações/variáveis causais verdadeiras. Entretanto, nem sempre é possível determinar a causa de um dado evento, limitando as relações causais deste evento a outros eventos, cujos movimentos permitem prever o movimento do evento de interesse. Por exemplo, o uso do tempo para prever as taxas de vendas de um produto. Obviamente o consumo de um determinado produto não depende da passagem do tempo, porém a relação temporal fornece relações causais satisfatórias sobre o consumo e é amplamente aceita na análise de mercado de um produto particular.

140

2. Validade dos dados brutos: Diz respeito a problemas de medição, refletindo o questionamento: os dados refletem o que são (ou o que se espera deles)? a. Precisão. É a capacidade de identificar e medir corretamente o que é desejado. b. Imparcialidade. É a garantia de que os dados estão corretamente registrados. c. Representatividade. É a garantia de que o universo do qual os dados são extraídos é identificado adequadamente e representam o sistema real. No caso de dados estatísticos, esse critério deve considerar ainda que houve aleatoriedade na coleta das amostras. 3. Validade dos dados estruturados: Dados estruturados são dados brutos nos quais alguma manipulação foi realizada. Em cada etapa da manipulação, deve-se revisar sua execução para garantir que o resultado seja válido. Manipulações simples sobre os dados, como a aplicação de uma média, traz consigo inúmeras oportunidades para que erros sejam propagados no desenvolvimento, como adições ou divisões erradas ou considerações sobre o tamanho do conjunto, etc. Identificar a validade dos dados estruturados é tão dependente da natureza da manipulação/estruturação que é difícil generalizar esse tópico. 4. Validade lógica: Preocupa-se com a garantia de uma progressão lógica da construção do modelo para a solução. a. Exatidão da solução. É a garantia de que as manipulações matemáticas são corretas e precisas. b. Fluxo lógico. É a garantia de que há um continuum lógico nas associações dos elementos do modelo. c. Clareza. É a capacidade de identificar omissões no modelo e em suas variáveis relevantes. 5. Validade preditiva: A validade preditiva lida com erros de previsão do modelo. Na validade preditiva busca-se por todos os erros e divergências entre o resultado real e o resultado previsto para qualquer uma das relações dentro do modelo.

141

Validade operacional: A validade operacional lida com a importância/impacto das divergências encontradas sob a validade técnica. Deve-se reconhecer que a validade operacional versa sobre a tomada de decisão – quer seja pela mudança de expectativas em relação ao resultado, quer seja na modificação do modelo para que seu resultado seja mais consistente com as expectativas – e deve ser ponderada nas camadas relacionadas a tomada de decisão em cada etapa de desenvolvimento. Schellenberger (1974), lista alguns subcritérios para a avaliação da validade operacional de modelos, a saber: grau de melhoria, teste de erro de extremos, efeitos de ações perto do ótimo, métodos subjetivos, validade de implementação. Validade dinâmica: A validade dinâmica tenta garantir que o modelo continuará válido durante seu ciclo de vida. O que inclui provisões para a atualização de parâmetros, bem como para a expansão da cobertura do modelo quando apropriado e para a revisão do sucesso do modelo ao longo do tempo e para as modificações necessárias. A despeito dos critérios de validade de modelos e da necessidade de validação dos modelos, aos moldes de Coyle e Exelby (2000), gerados no processo ARES, não cabe à descrição do processo a definição de técnicas ou esquemas específicos para tal. Para tanto, sugere-se a leitura dos trabalhos de Martis (2006), Shreckengost (1985), Balci (1994), e do trabalho de Küster e Abd-El-Razik (2007), voltado para a validação da transformação de modelos.

5.3.4 O esforço de modelagem

Sob uma perspectiva conceitual, o esforço de modelagem, estruturado na figura 5.12, define a teleologia do processo ARES. Analisada enquanto ciência, o esforço de modelagem define os contextos sob os quais o sistema deve ser entendido e interpretado e os graus de abstração adequados em cada etapa do desenvolvimento. Apreciado sob esta ótica, o esforço de modelagem abrange os contextos do domínio, contradomínio e imagem do problema, cujas definições são análogas as das relações e funções na matemática. Na qualidade de engenharia, o

142 esforço de modelagem descreve o escopo, objetivos, requisitos e constraints de cada uma de suas etapas, alicerçados nos contextos específicos das disciplinas envolvidas na pesquisa aplicada – contexto tecnológico e contexto técnico- científico.

143

Figura 5.12 - Esforço de modelagem do processo ARES

Fonte: Autoria própria

144

Já sob o entendimento da modelagem enquanto cultura, o esforço de modelagem deve ser flexível o suficiente para se adequar aos métodos e práxis do grupo de pesquisa. À vista disso, a esse esforço deve ser atribuído não só a qualidade de ferramenta-independente, mas a qualidade de método-independente, definindo o que deve ser alcançado sem definir como alcança-lo.

5.3.4.1 Modelagem cognitiva

O propósito do esforço de modelagem cognitiva é a definição do domínio de aplicação dentro do domínio do problema. Desta forma, busca-se a captura do conhecimento essencial sobre o domínio do problema através de representações visuais e ontologias de domínio específico, permitindo delinear o escopo da pesquisa e o domínio de aplicação do contexto do domínio do problema. Os conhecimentos específicos dos domínios aplicáveis e dos stakeholders envolvidos na pesquisa – parte no contexto técnico-científico, parte no contexto do domínio do problema – somados à análise do contexto tecnológico, conjunto de conhecimentos, técnicas e tecnologias disponíveis ao grupo de pesquisa, possibilitam a apreciação do contradomínio do problema (espaço solução) sob o viés da viabilidade. O esforço de modelagem cognitiva empenha-se na criação de artefatos de entendimento que nortearam o racional e objetivos da pesquisa. Modelo mental (modelo de contexto): Representações das estruturas, elementos e interfaces do domínio do problema. Ontologia de domínio específico: Coleção dos termos, informações e conceitos pertencentes a um domínio particular. Mais que um dicionário, uma ontologia é um comum-acordo sobre o uso de seus conceitos constituintes. Protótipo de viabilidade: Modelos e rotas tecnológicas usadas para argumentar sobre a viabilidade técnica e escopo de desenvolvimento, e avaliar alternativas e abordagens de desenvolvimento, além de riscos técnicos preliminares. Cenários operacionais: Descrição das principais entidades do domínio do problema e suas capacidades, comportamentos, relações e interações.

145

A fim de manter o esforço coerente, os artefatos produzidos devem apresentar interoperabilidade intensional 5 . Neste contexto – assim como na definição filosófica de intensão (MARTIN, 1963) – os símbolos, componentes e modelos devem compartilhar propriedades, qualidades conotadas, conteúdos conceituais e características de aplicabilidade, tornando o conjunto dos artefatos produzidos a compreensão do domínio do problema (na perspectiva linguística da compreensão como a coleção de todas as intensões de um objeto) e conferindo composabilidade (composability) e interoperabilidade às simulações mentais. De maneira geral, a modelagem cognitiva se caracteriza pela criação majoritária de modelos e artefatos independentes de computação (CIM), com o uso de diagramas e desenhos quem visam capturar os modelos mentais dos stakeholders e especialistas de domínio, e pela simulação mental – porém não se exclui o uso de modelos e simulações computacionais nesse esforço de modelagem. O que melhor caracteriza um modelo mental é sua incompletude. Seu conteúdo é apenas uma representação parcial do fenômeno ou objeto e seu escopo é limitado (SANDERSON; MURTAGH, 1990). Esses modelos são essencialmente construídos a partir do conhecimento necessário para alcançar um determinado objetivo e de dados extraídos do meio. A representação resultante do mundo é aquela em que as características essenciais do fenômeno são enfatizadas, enquanto as demais características e dados periféricos são negligenciados; assemelhando-se a uma representação em forma de figura (picture-like representation), que preserva as características distintivas ou únicas do objeto e onde o mapeamento entre estas e as características correspondentes na representação é feita de maneira não arbitrária. A este respeito, modelos mentais são versões simplificadas e cognitivamente aceitáveis de uma realidade complexa. A natureza dos modelos metais, figura 5.13, abrange três funções distintas: descrever, explicar e predizer. Descrever envolve o conhecimento do propósito do sistema e de sua estrutura. Explicar envolve uma função indutiva que mapeia ou

5 O conceito de interoperabilidade intensional deve ser encarado como o sétimo nível no modelo de níveis de interoperabilidade conceitual (LCIM) (TOLK et al., 2007).

146 raciocina a partir da observação para a interpretação. Predizer, por outro lado, envolve uma função dedutiva que usa o estado atual do sistema e mapeia ou raciocina a partir da estrutura de conhecimento de condições e situações gerais para expectativas de condições específicas (ROUSE et al., 1992).

Figura 5.13 - Natureza dos modelos mentais. a) Descrever, especifica a estrutura e propósito de um sistema; b) Explicar, descreve o comportamento de um sistema; e, c) Predizer, prevê o estado de um sistema com base em condições e dados conhecidos (simulação mental).

Fonte: ROUSE et al., 1992

A construção de um modelo mental quase sempre se baseia em evidências parciais; consequência das limitações cognitivas, ou racionalidade limitada (SIMON, 1957), em que os problemas são resolvidos de acordo com um trade-off intuitivo de custo-benefício. O principal problema inserido por esta “economia cognitiva”, é o viés de confirmação (KLAYMAN; HA, 1989), no qual confirmações parciais são facilmente aceitas e onde os modelos mentais tendem a “esperar” dados consistentes ao invés de procurar por evidências contraditórias. Para superar estes problemas, a integração de estruturas e representações externas é crucial: esboços em papel, protótipos construídos a partir de dados extraídos do domínio do problema, etc.; o que, no processo ARES, corresponde aos modelos mentais (modelos de contexto), protótipos de viabilidade e cenários operacionais. A interação com estes modelos externos é análoga à simulação mental – ambos envolvem a construção e a manipulação da visualização para o raciocínio simulado –, contudo a primeira pode ser acessada por diferentes indivíduos, sendo mediadora de um comum-acordo entre as diferentes partes. O trabalho de Ricci et al. (2014)

147 traz uma interessante perspectiva, na forma de um framework, sobre o uso de modelos visuais na exploração dos modelos mentais dos stakeholders sobre suas preferências, desempenho e valor esperados para um sistema.

5.3.4.2 Modelagem conceitual

Modelagem conceitual tem por propósito desenvolver uma representação adequada da porção do mundo real que se aplica ao domínio e contradomínio do problema – representações não dependentes de plataforma (e de software/ferramenta não específico) do sistema de interesse, descrevendo objetivos, interfaces, comportamentos e funcionalidades. O que deve estar claro no esforço de modelagem conceitual, e durante todo o ciclo de vida do projeto, é que o modelo conceitual é um artefato persistente. A disponibilidade, ou não, de dados, por exemplo, pode exigir ajustes no modelo conceitual, implicando na revisão contínua deste modelo. Como tal, a modelagem conceitual não é um processo único, mas um que é repetido e refinado várias vezes durante a execução da pesquisa. Os artefatos produzidos nesse esforço de modelagem fornecem um roteiro a partir da definição do domínio de aplicação e dos objetivos para o design e implementação do sistema. Modelo em “caixa preta” (modelo conceitual): Representação independente de plataforma do sistema de interesse, seu escopo, interfaces, comportamentos e funcionalidades. Cenários conceituais: Conjunto de especificações suficiente para o design do ambiente de simulação e necessária para compor o contexto dos modelos conceituais. Assente em uma compreensão do domínio de aplicação, é a modelagem cognitiva que impulsiona a modelagem conceitual e a derivação dos modelos e cenários conceituais. No âmbito do processo ARES, entende-se o modelo conceitual tal qual Robinson (2008), distinguindo quatro componentes principais: objetivos, entradas, saídas e conteúdo. Objetivos descrevem o propósito do projeto

148 de pesquisa, do esforço de modelagem e do modelo. Entradas descrevem fatores experimentais ou variáveis de decisão que podem ser controladas/alteradas para alcançar os objetivos. Saídas descrevem fatores que podem ser usados para indicar se os objetivos foram ou não alcançados e para compara diferentes alternativas. Finalmente, o conteúdo do modelo consiste nos componentes representados no modelo e suas interconexões. O conteúdo pode ser divido em duas dimensões: • O escopo do modelo: o limite do modelo ou a amplitude e complexidade do sistema que devem ser incluídos no modelo. • O nível de detalhe: o detalhe a ser incluído para cada componente no escopo do modelo. O conteúdo do modelo é determinado, em parte, pelas entradas e saídas, em que o modelo deve ser capaz de aceitar e interpretar as entradas e fornecer as saídas necessárias. Ao tomar decisões sobre o conteúdo do modelo, várias suposições e simplificações são introduzidas adotando-se certos pontos de vista sobre o sistema. De maneira geral, suposições são feitas quando há incertezas ou crenças sobre o domínio de aplicação, enquanto simplificações são incorporadas ao modelo para permitir o desenvolvimento oportuno do modelo, reduzindo sua complexidade, e para melhorar sua compreensão e transparência. Os modelos conceituais devem evoluir de uma descrição de engenharia do domínio de aplicação para uma representação da dinâmica do SOI. Para tanto devem apresentar, num primeiro momento, interoperabilidade conceitual – sexto nível no modelo de níveis de interoperabilidade conceitual de Tolk (TOLK et al., 2007) – e então interoperabilidade dinâmica (quinto nível do LCIM). No nível conceitual, os modelos estão completamente cientes de cada informação, processo, contextos e suposições adotadas no esforço de modelagem. Isso requer que os modelos conceituais sejam documentados com base em métodos de engenharia, permitindo sua interpretação e avaliação pelos desenvolvedores. Já no nível dinâmico, os processos que usam os símbolos trocados entre elementos do domínio de aplicação e o SOI são entendidos. Desta forma, os modelos conceituais compreendem as mudanças de estados em ocorrem nas suposições e constraints que cada um de seus componentes e elementos realiza ao longo do tempo. Nesse

149 nível de interoperabilidade, as suposições e constraints dos processos são descritas sem ambiguidade e o comportamento dos componentes do domínio de aplicação e do SOI são previsíveis durante a interoperação de seus modelos. Sobre qualquer faceta do processo de modelagem, não há modelo sem que haja um conceito do que ser modelo, sem que haja um modelo conceitual. Porém, tornar este modelo explícito fornece um meio de comunicação e rastreabilidade entre os envolvidos no projeto de pesquisa, trazendo, senão um consenso, uma acomodação sobre a natureza do que será desenvolvimento.

5.3.4.3 Modelagem sistêmica

A modelagem sistêmica é voltada para a exploração do contradomínio do problema. Seu objetivo é a definição das macro-funções e subsistemas do SOI, com base em seu escopo, interfaces, comportamentos e funcionalidades (modelo em “caixa preta”). Esse esforço deve ser capaz de definir unicamente um subsistema ou macro-função sem especificar uma solução particular para este (modelo em “caixa cinza”). As informações, mensagens e símbolos trocados internamente devem ser entendidos mutualmente entre os subsistemas participantes – possuindo a mesma referência lógica –, porém sem definir o processo para a formação ou processamento dessas informações. Em outras palavras, cada macro-função e subsistema deve se comportar tal qual um sistema em “caixa preta”. Modelo em “caixa cinza”: Decomposição do SOI em subsistemas e macro- funções, definindo suas interfaces, interações, constraints e comportamentos. Catálogo de soluções: Catálogo de soluções aplicáveis para cada macro-função definida no sistema. Para cada solução no catálogo, especifica suas características operacionais e técnicas, além das premissas e simplificações adotadas em seu modelamento. Este esforço de modelagem deve decompor o SOI empregando diferentes pontos de vista, abordando as diferentes facetas do sistema, enquanto que o catálogo de soluções deve empregar diferentes perspectivas sobre as propriedades de cada elemento do sistema. Para esse feito, os subsistemas e macro-funções

150 devem estar cientes do contexto no qual os símbolos que eles trocam são usados – interoperabilidade pragmática, quarto nível do LCIM. Em outras palavras cada subsistema é ciente das propriedades e do papel desempenhado pelos demais subsistemas com os quais troca informações, implicando no compartilhamento de um modelo lógico de referência comum entre os elementos do sistema, seus subsistemas e macro-funções. Diversas abordagens possibilitam a decomposição coerente do sistema em suas partes constituintes, macro-funções e subsistemas. Entretanto cabe à expertise e processos estabelecidos no grupo de pesquisa a escolha e aplicação de uma ou outra abordagem. Sendo igualmente possível que um sistema seja decomposto por uma estratégia tão simples quanto a decomposição por funcionalidades, tal qual aplica pelo processo FDD, ou através de estratégias mais elaboradas como a aplicação da ontologia FBS (do inglês, Funciton-Behaviour- Structure) de Gero (GERO; KANNENGIESSER, 2014) na representação dos objetivos, comportamentos e partes constituintes do sistema.

5.3.4.4 Modelagem do sistema-solução

Este esforço de modelagem visa a definição do sistema-solução e delimitação do espaço imagem do problema. O sistema-solução, definido a partir da composição semanticamente interoperável de elementos do catálogo de soluções para um dado “espaço de interesse” ou propósito, constitui o último estágio da especificação do sistema enquanto artefato independente de tecnologia (modelo independente de plataforma – PIM). Enquanto o espaço imagem do problema é delimitado pela soma das propriedades, constraints e premissas dos elementos do catálogo de soluções usados na composição do sistema-solução. Modelo em “caixa branca”: Resultado da composição de elementos do catálogo de soluções que formam o sistema-solução. Repertório tecnológico: Catálogo de tecnologias potenciais para os “espaços de interesse” ou regiões do sistema-solução. Para cada tecnologia no repertório,

151 especifica suas características operacionais e técnicas, além dos impactos dessa tecnologia no desenvolvimento da pesquisa. Cenários executáveis: Especificação para execução dos cenários conceituais no ambiente de simulação proposto. O sistema-solução deve garantir que seus componentes compartilham o mesmo “espaço de interesse” e propósito (ou objetivo), certificando-se que a composição possui significado semântico. Desta forma, da estrutura lógica da troca de informações entre os elementos do SOI, presente no modelo em “caixa cinza” do sistema candidato, um modelo de referência comum dessas trocas deve ser compartilhado entre os componentes (transformação PIM para PIM), definindo e harmonizando o significado dos dados e informações trocadas e os conteúdos dos pedidos de troca. Neste estágio os componentes do sistema-solução interoperam no terceiro nível do LCIM, interoperabilidade semântica.

5.3.4.5 Modelagem da arquitetura do sistema

O esforço de modelagem da arquitetura do sistema busca estabelecer a infraestrutura e o aporte do sistema-solução na arquitetura proposta, considerando as tecnologias específicas empregadas e suas interfaces. A principal característica da modelagem da arquitetura do sistema é a definição da imagem do problema a partir da arquitetura do sistema e particionamento das macro-funções, guiada por transformação PIM para PDM do modelo em “caixa branca” do sistema-solução. O artefato resultante desse esforço de modelagem estabelece um elo de refinamento constante entre a especificação do sistema e seu design, criando uma interface controlada, bem definida e ainda assim flexível entre as diferentes disciplinas envolvidas no design e implementação do sistema. Modelo de arquitetura: Produto do particionamento e aporte das macro-funções nas tecnologias e arquitetura propostas para o sistema-solução. Para o particionamento e aporte das macro-funções e componentes do sistema-solução na arquitetura proposta, uma estrutura/sintaxe comum para a troca de informações e formato de dados deve ser aplicada. Essa estrutura, sintetizada

152 num protocolo comum de troca de pacotes de dados (agrupados em símbolos), representa um modelo físico de dados compartilhado entre os diferentes componentes, e confere ao sistema interoperabilidade sintática (segundo nível de interoperabilidade do LCIM).

5.3.4.6 Modelagem do design do sistema

O propósito da modelagem do design do sistema é emular e criar uma virtualização da implementação do sistema em ambiente simulável. Os artefatos desse esforço de modelagem definem o contrato de implementação de cada disciplina e de cada componente do sistema, e visam um sistema correto por construção. Não existe uma linguagem ou ferramenta universal que permita a modelagem de toda e qualquer aplicação, ou mesmo que suporte todas as disciplinas envolvidas no desenvolvimento e implementação do sistema. Desta forma, espera-se que os modelos criados nesse esforço (esquemáticos de circuitos eletrônicos, códigos simuláveis, etc.) sejam dependentes da disciplina e da cultura de desenvolvimento existente no grupo de pesquisa. Modelo encapsulado (Protótipo virtual): Produto da adequação do modelo de arquitetura do sistema-solução, macro-funções e subsistemas à estratégia de design. Modelo da abstração de tecnologia: Resultado da estratégia de design sobre a arquitetura do sistema. A somatória dos esforços de modelagem até então, constituem uma abordagem homogênea de co-design (JERRAYA et al., 1999), esquematizada na figura 5.14, em que uma visão independente de implementação, não específica de uma ou outra disciplina da engenharia, da especificação do sistema dá origem ao processo de co-design, primeiro pelo particionamento do sistema em elementos de distribuídos entre as diferentes disciplinas (hardware, software, etc.), depois pela criação de um protótipo virtual do sistema e, por fim, pela sua implementação.

153

Figura 5.14 - Co-design: Modelagem homogênea

Fonte: JERRAYA et al., 1999 (Reproduzido com autorização)

O modelo encapsulado do sistema e o de abstração da tecnologia devem ser específicos o suficiente para satisfazer as características da interoperabilidade técnica, nível um do modelo LCIM. Neste nível, deve existir uma infraestrutura de comunicação e troca de dados e sinais, permitindo a troca de sinais específicos, bits/bytes, etc.

5.3.4.7 Modelagem da implementação do sistema

O esforço de modelagem da implementação do sistema está vinculado as diferentes disciplinas envolvidas na implementação do sistema e suas ferramentas específicas. O objetivo desse esforço é a criação de diagramas computacionais da implementação do sistema. O conjunto desses diagramas computacionais, chamado modelo de implementação, representa o mais baixo nível de abstração que cumpre o critério de ser condição necessária e suficiente à implementação de cada componente do sistema, sendo constituído de códigos fontes, CADs, layouts de circuitos eletrônicos, dentre outros. Modelo de implementação: Representação executável ou em relação 1:1 na tecnologia alvo dos componentes do sistema. Co-simulação: Conjunto de técnicas de co-simulação e implementações parciais do workbench de verificação unitária e integração.

154

Os artefatos gerados durante a modelagem da implementação do sistema não apresentam interoperabilidade, implicando num sistema stand-alone e atendendo ao nível zero do modelo LCIM.

5.4 O PROCESSO ARES DESCRITO SOB A PERSPECTIVA DA GESTÃO DO CONHECIMENTO

Não se deve entender ‘gestão do conhecimento’ como a manipulação ou controle do conhecimento – o termo em si é pobre, mas acostumou-se a usá-lo (SVEIBY, 2011). No processo ARES, gestão do conhecimento indica a criação de condições favoráveis para a aquisição, retenção, apropriação, transformação e transferência6 do conhecimento, beneficiando a consecução dos objetivos de uma determinada organização, ou grupo de pesquisa, ou programa de pesquisa. Iniciativas de gestão do conhecimento devem necessariamente considerar as características do ambiente no qual serão implementadas. Tais características dizem respeito, principalmente, à natureza do conhecimento – bem como as forças que condicionam a sua criação – a cultura que envolve os indivíduos e o seu comportamento em relação à informação e ao conhecimento e as peculiaridades dos processos de comunicação próprios do meio (ALBUQUERQUE, 2016; LEITE, 2006).

5.4.1 Estratégias da gestão do conhecimento associada ao processo ARES

No que concerne à gestão do conhecimento, Stollenwerk (2001) sintetiza os principais modelos descritos na literatura em uma estrutura básica contento seus processos essenciais. São eles: identificação; captura ou aquisição; seleção e validação; organização e armazenagem; compartilhamento e disseminação; aplicação; criação.

6 Entende-se por ‘transferência de conhecimento’ o processo que permite o compartilhamento e a assimilação do conhecimento de um indivíduo para outro (LEITE, 2006).

155

5.4.1.1 Identificação

A identificação ou mapeamento do conhecimento é o levantamento de informações, conhecimentos e competências que são usados e criados no ambiente da organização. No enfoque operacional, consideram-se os conhecimentos, habilidades e tecnologias para apoiar as atuais competências; já no enfoque estratégico, consideram-se os conhecimentos e habilidades existentes, que podem ser transferidas, versus aqueles que devem ser adquiridos para apoiar o desenvolvimento de novas competências (STOLLENWERK, 2001). No âmbito da pesquisa aplicada de engenharia, o mapeamento do conhecimento específico ao domínio do problema e a identificação de fontes de conhecimento relacionadas complementam o processo de identificação. Neste contexto, há duas atividades relacionadas à aquisição de conhecimento de domínio específico (domínio do problema) que devem ser consideradas na abordagem de gestão do conhecimento: a identificação de fontes autorizadas/acreditada de conhecimento e a identificação dos limites e lacunas de conhecimento. Identificação de fontes autorizadas/acreditadas de conhecimento: Identificar, mapear e classificar as fontes autorizadas e/ou acreditadas de conhecimento onde se possa buscar informações corretas e/ou confiáveis que descrevem um determinado domínio. Uma fonte autorizada de conhecimento pode ser qualquer coisa, desde livros, artigos, páginas web, estudos de caso, até profissionais ou práticos do domínio em questão. Identificação dos limites e lacunas de conhecimento: Esta atividade diz respeito à análise de cobertura dos modelos mentais e conceituais existentes frente aos objetivos, requisitos e propósitos da pesquisa. Esta análise visa assegurar que ou o conjunto de requisitos seja preenchido ou alternativamente, se o conhecimento correspondente a um ou mais requisitos estiver faltando, a aquisição de conhecimento adicional se encarregará dessa lacuna de conhecimento.

156

5.4.1.2 Aquisição

O processo de captura representa a aquisição de conhecimentos, habilidades e experiências necessárias para criar e manter as competências essenciais e áreas de conhecimento selecionadas e mapeadas (STOLLENWERK, 2001). A aquisição de conhecimento no que concerne a gestão do conhecimento diz respeito ao processo de reunir, estruturar e documentar informações e conhecimento. No entanto, as informações e conhecimentos necessários para um determinado propósito muitas vezes não estão documentadas em qualquer lugar e só estão disponíveis através dos especialistas de domínio; conhecimento tácito. Devido à falta de uma estrutura sistemática para a aquisição de conhecimento, é extremamente difícil organizar e planejar a aplicação adequada e conveniente de uma ou outra técnica ou método para a aquisição de conhecimento. No processo ARES adota-se a abordagem construtivista a respeito da aquisição do conhecimento (NYSTEDT; MAGNUSSON, 1982). Em contraste à abordagem objetivista, que presume o conhecimento como um conjunto de informações adquiridas que pode ser transferido, emprestado, armazenado, exibido, empacotado e comprada ou vendido como qualquer outra mercadoria, a abordagem construtivista define um problema (e sua solução) como um artefato de processos cognitivos. Essa abordagem pressupõe que um propósito ou meta pode ser compartilhado com outras pessoas, mas pode haver vários métodos individuais para atingi-lo; diferentes especialistas de um mesmo domínio específico podem usar diferentes métodos para resolver um mesmo problema. Para a aquisição do conhecimento, o foco é identificar as características da tarefa que são salientes para o especialista de domínio e explicitar os procedimentos cognitivos usados (COMPTON; JANSEN, 1990). Sob o ponto de vista conceitual, o processo ARES assenta-se de certa forma (ainda que não intencionalmente) na visão de Shaw e Woodward (1990) sobre o processo de aquisição de conhecimento de especialistas de domínio, sintetizada na figura 5.15. No trabalho, intitulado Modeling Expert Knowledge (SHAW;

157

WOODWARD, 1990), os autores trazem ainda uma lista das principais técnicas para a aquisição de conhecimento de especialistas.

Figura 5.15 - Processo de aquisição de conhecimento de especialistas de domínio

Fonte: SHAW; WOODWARD, 1990 (Reproduzido com autorização)

O primeiro requisito é definir o sistema com o qual o especialista interage, sistema alvo ou SOI. A princípio, nenhum modelo intrínseco existe no sistema alvo, mas sim uma sequência de atividades ou eventos, a medida que o especialista

158 interage com o sistema alvo, produz-se muitos modelos mentais, de onde o especialista é capaz de isolar e definir “primitivas”, representando-as de forma simbólica. Do modelo mental, cria-se o modelo conceitual do sistema alvo. O modelo conceitual encontra representação nas primitivas de comunicação da linguagem e do comportamento. É esse modelo conceitual que está disponível para os outros e que é base para representar os modelos usados para atender às demandas de tarefas do sistema alvo. Procedimentos de elicitação, elucidação e análise informal, que se baseiam na introspecção e comunicação do especialista de domínio, produzem as bases intermediárias de conhecimento, fonte de conhecimento acreditado sobre o domínio específico. Essas bases de conhecimento têm como funções principais ser uma representação para exibição ao especialista, para a avaliação e confirmação sejam possíveis, e servir como ponto de partida para ulterior elicitação. O modelo conceitual do especialista se torna então o foco de mais esforços de modelagem com o objetivo de selecionar um conjunto de primitivas desse modelo para ser usado em modelos que capturam o conhecimento tácito do especialista sobre o sistema alvo. Esses modelos representam as inter-relações entre as demandas de tarefas do sistema alvo e os modelos para atender às demandas do modelo conceitual (modelo operacional ou de trabalho). Ao analisar formalmente esses modelos, uma base computacional de conhecimento pode ser identificada e codificada. Assim como dos processos anteriores, esse processo pode ser iterado e refinado pela extração de estruturas de conhecimento produzidas até que a base computacional de conhecimento seja suficientemente bem implementada para representar os modelos do modelo conceitual do sistema alvo. Introspecção e elicitação: Os procedimentos de elicitação estruturam as informações do especialista de domínio e presume-se que essas informações refletem alguns dos conhecimentos disponíveis que caracterizam a representação do modelo mental do especialista da tarefa em particular, conforme ela é interpretada e representada pelos procedimentos de elicitação.

159

Comunicação e análise: Os procedimentos informais de análise apoiam as primeiras tentativas de comunicação do especialista e extraem significado do material linguístico do modelo conceitual e das ordenações e estruturas parciais das bases intermediárias de conhecimento. Já os procedimentos formais de análise produzem um modelo bem definido, conceitualmente ordenado, teoricamente consistente da tarefa e contexto em consideração. Esse modelo pode ser visto como uma teoria completa do conhecimento específico, baseada no uso consistente de conceitos e uma aplicação metódica de regras formais que é capaz traçar as origens de como e por que o conhecimento foi construído e documentar suas transformações. Formalização e implementação: Os processos de implementação recorrem à estrutura formalizada dos modelos do modelo conceitual. Com base em suposições subjacentes sobre o conhecimento, esses processos selecionam, ordenam, organizam e representam elementos do modelo de uma forma conducente à operação. No processo ARES, os processos de elicitação, análise e implementação guiam a aquisição de conhecimento nos esforços de modelagem cognitiva e conceitual, gerando os modelos mentais e a ontologia de domínio específico, que, acrescidos dos cenários operacionais, forma a base intermediária de conhecimento, e o modelo em “caixa preta” do sistema, que são essencialmente modelos computacionais independentes de plataforma que representam, junto aos cenários conceituais, a base computacional de conhecimento.

5.4.1.3 Seleção e validação

Atividade com a finalidade de filtrar, avaliar e sintetizar o conhecimento para fins de sua aplicação. Na concepção de Stollenwerk (2001), a operacionalização desse processo dá-se em sete etapas: 1) determinar a relevância e valor do conhecimento ou da informação; 2) determinar o grau de confiabilidade desse conhecimento; 3) identificar e consolidar o conhecimento útil; 4) contrair, desenvolver e criar conhecimentos não disponíveis; 5) reduzir o grau de incerteza

160 do conhecimento não comprovado; 6) identificar e propor soluções de problemas relacionados a conhecimentos conflitantes; 7) estabelecer visões múltiplas para casos de conhecimentos conflitantes não solucionados. O trabalho de Fernandes et al. (2018) explora o uso de sensemaking e visual analytics na identificação e superação de lacunas e conflitos de conhecimento envolvendo a tomada de decisões de design em pesquisa interdisciplinar através da construção de múltiplas visões sobre um modelo comum. O produto desse processo é o conjunto de conhecimento validado. Sob a ótica do processo ARES, diz-se de conhecimento validado, o conjunto de informações e conhecimentos acreditados (e autorizados) disponível, necessário e suficiente para o desenvolvimento dos cenários conceituais e modelo em “caixa preta” do sistema. A validação do conhecimento é, em última instância, a validação do modelo conceitual do sistema, visto que para que o modelo seja dito válido, é necessário determinar se todas as abstrações usadas na modelagem são adequadas/suficientes para o propósito determinado e uso do produto final – no caso da aquisição do conhecimento de especialistas de domínio, o modelo conceitual deve ser revisado e examinado pelo especialista, cuja realidade foi capturada, para verificar se o conhecimento aplicado no modelo está correto e representa completamente a atividade ou tarefa. No contexto da avaliação ontológica, a correspondência da estrutura ontológica do processo ARES (vide triângulo de Couclelis, Seção 5.1.3), em suas modelagens cognitiva e conceitual, e o processo de seleção e validação do conhecimento se dá pelo propósito e uso pretendidos de seus modelos. O trabalho de Gangemi et al. (2005) aborda a formalização do que chama de medidas funcionais, diagramada na figura 5.16, através da relação entre a conceitualização e a ontologia e as correspondências de sua estrutura. Nessa formalização, uma ontologia é uma teoria lógica projetada de tal forma que o conjunto de seus modelos relativos à conceitualização, sob as premissas e comprometimentos de sua interpretação, é uma aproximação adequada do domínio específico. Esta abordagem permite a avaliação da ontologia quanto a seu propósito, o que, no contexto da gestão do conhecimento empregada no processo ARES, permite a

161 avaliação, balizada pelo propósito da pesquisa, de seus esforços de modelagem cognitiva e conceitual frente à aquisição, seleção e validação do conhecimento.

5.4.1.4 Organização e armazenagem

O objetivo desse processo é garantir a recuperação rápida, fácil e correta do conhecimento, por meio da utilização de sistema de armazenagem efetivos. O processo ARES faz uso de uma estrutura ontológica bem definida que serve ao propósito de organizar e reter (armazenar) o conhecimento capturado nas fases iniciais e gerados em seu ciclo de desenvolvimento, entre modelos mentais, conceituais, de sistema, etc.

5.4.1.5 Compartilhamento

Pressuposto básico e primordial para a transformação de informações e experiências isoladas em algo que toda a organização possa utilizar. Diz respeito ao processo de compartilhamento e disseminação do conhecimento que já está na organização. Compreende questões importantes em todo o processo tais como distribuição do conhecimento de forma seletiva, ao maior número de usuários possível, em tempo hábil e local apropriado (LEITE, 2006). O compartilhamento ou disseminação do conhecimento dá-se, então, por meio de um sistema de comunicação (contíguo aos demais processos da gestão do conhecimento) constituído por meios complementares entre si: os meios de comunicação formais, que se dedicam ao conhecimento codificado/explícito, e os informais, que lidam principalmente do conhecimento tácito. Tratando-se de pesquisa aplicada em engenharia, o processo ARES apoia-se na comunicação científica como meio de disseminação e compartilhamento do conhecimento. O sistema de comunicação científica formal veicula o conhecimento por meio de registros documentais estáticos: relatórios de pesquisa, anais de congressos e conferências, teses e dissertações, livros, dentre outros. Esses meios lidam

162 majoritariamente com o conhecimento explícito, justificável e/ou factual e estão vinculados à serviços de informação, indexação, bibliotecas, etc. Já o sistema informal compartilha tanto conhecimento explícito quanto tácito. Nesse caso a relações interpessoais entre indivíduos e grupos de pessoas constituem o meio de disseminação do conhecimento: reuniões de grupos de pesquisa, conferências, seminários, grupos de discussão, etc. As interações e interrelações entre os meios formais e informais descrevem o grau de cristalização do conhecimento difundido (KRIEGESKORTE, 2012), que aumenta com o número de pessoas em cuja memória a comunicação é armazenada e com a confiabilidade, permanência e citabilidade do armazenamento baseado em mecanismos de indexação, partindo de conversas informais entre duas pessoas e discussões de grupos de pesquisas a artigos revisados por pares (peer-review) e publicados. Um conhecimento gerado, ou mesmo adquirido, numa pesquisa deve ser afirmado dentro da comunidade científica por meio dos mecanismos de compartilhamento do conhecimento, tendo no grau de cristalização a métrica de sua abrangência e confiabilidade.

5.4.1.6 Aplicação

Tão importante quanto identificar, adquirir e compartilhar o conhecimento, é aplica-lo de modo a produzir valor e benefícios concretos. Há duas etapas no processo de aplicação do conhecimento. A primeira é a aplicação propriamente dita de conhecimento relevante, confiável e de alto valor agregado em processos decisórios, em soluções de problemas operacionais, em processos de inovação e de aprendizagem. A outra etapa é o registro das lições aprendidas e dos ganhos obtidos com a aplicação. A aplicação do conhecimento pode ser vista como processo inerente do desenvolvimento em pesquisa aplicada. No processo ARES esse processo é traduzido no encadeamento de suas atividades de modelagem, que fornecem um fluxo de desenvolvimento uniforme e de validação contínua, favorecendo a aplicação oportuna do conhecimento.

163

5.4.1.7 Criação

O processo de criação de um novo conhecimento envolve as seguintes dimensões (STOLLENWERK, 2001): aprendizagem, externalização, lições aprendidas, criatividade, pesquisa, experimentação, descoberta e inovação. Para Nonaka e Konno (1998), o processo de criação do conhecimento organizacional inicia-se com o compartilhamento do conhecimento tácito entre indivíduos (socialização), amplificando o conhecimento individual inexplorado dentro da organização. Numa segunda etapa, o conhecimento tácito compartilhado é convertido em conhecimento explícito (externalização) na forma de um novo conceito, que é então justificado e tem seu valor é determinado pela organização. Uma vez validados, os novos conceitos são convertidos em arquétipos que podem assumir a forma de um protótipo ou mecanismo operacional, convertendo o conhecimento explícito num conhecimento explícito organizacional (combinação). A última fase amplia o conhecimento criado e armazenado na organização para seus grupos e equipes internos, permitindo que o indivíduo se aproprie do conhecimento explícito organizacional e o internalize na forma de conhecimento tácito (internalização). No contexto da gestão do conhecimento aplicada ao processo ARES, os modos de conversão – socialização, externalização, combinação e internalização – são assentados nas atividades de modelagem e simulação e têm, na estrutura ontológica do processo, mecanismo facilitador.

164

6 CASO DE ESTUDO

Num processo de desenvolvimento incremental iterativo como o prescrito pela meta-metodologia aplicada no desenvolvimento do processo ARES, o teste é realizado não apenas para criar confiança no objeto testado, neste caso no processo em si, mas também para guiar o desenvolvimento concentrado os esforços no atendimento aos requisitos e para mitigar riscos potenciais de desenvolvimento por meio da detecção precoce de falhas de design e implementação. E, embora a validação seja executada iterativamente no final das atividades de design e implementação, cada ciclo de design-implementação-teste deste mecanismo depende da atividade de teste para executar a verificação e a validação final do incremento do sistema que foi desenvolvido. No caso particular do desenvolvimento do processo ARES, tema desta dissertação, não se pôde desenvolver um caso teste capaz de verificar seu design a priori, tampouco um caso teste nasceu de seu ciclo de desenvolvimento. De maneira oposta, foi o processo ARES que emergiu durante seu caso de estudo, o projeto Proto85, contra o qual o processo foi verificado e validado, ajudando a refinar e esculpir gradualmente o processo para sua forma atual. No contexto do desenvolvimento de uma metodologia ou processo, a verificação é a garantia de que o processo implementa corretamente suas funções; em outras palavras, que o processo assegura que seus artefatos são produzidos com sucesso, culminando na produção do sistema alvo. Já a validação testa o processo em relação ao seu propósito e requisitos. Apesar de todo o esforço de revisão baseada em requisitos, realizada em cada ciclo de iteração durante o design do processo (Capítulo 4), que proporcionaram solidez e endereçaram riscos potenciais para a implementação do processo, não há validação sem a utilização, sem que haja a aplicação do processo pelo usuário em um ciclo de desenvolvimento. Ao invés de resumir o caso de estudo do processo ARES a um conjunto bem- sucedido de modelos bem encadeados, esse será usado para apresentar as

165 estratégias empregadas sobre os problemas de desenvolvimento do projeto em questão, desde sua concepção até sua entrega e finalização.

6.1 O PROJETO PROTO85

Fruto e subproduto do projeto USD (UtraSsongrafia Diagnóstica), encabeçado pela Rede Brasileira de Técnicas de Ultrassom (RBTU) e pelo Instituto de Pesquisas Eldorado (IPE), o projeto Proto85 visava a criação de uma cadeia de processamento de sinais capaz de demonstrar a aptidão da plataforma tecnológica desenvolvida no projeto raiz para a formação, aquisição, processamento e apresentação de imagens diagnósticas por ultrassom em tempo real. A estratégia adotada previa reproduzir a cadeia de processamento e técnicas típica dos primeiros equipamentos computadorizados de ultrassonografia para formação de imagens em modo-B, a exemplo do Acuson 128XP (Acuson Corporation ®), de 1983 – daí o codinome Proto85, ou protótipo 1985. Neste contexto apenas a fração do sistema proto85 responsável pelo processamento digital do sinal ultrassônico e formação de imagens modo-B (back-end digital), foi objeto e caso de uso do processo ARES; fração desenvolvida independentemente e concomitantemente tanto à plataforma em si, seu hardware e arquitetura, quanto ao aplicativo PC, responsável pela interface de visualização e configuração.

6.1.1 Modelagem cognitiva

Sob o contexto específico do projeto do back-end digital, a modelagem cognitiva deve considerar dois domínios do problema distintos, o da formação da imagem em modo-B por ultrassom, aos moldes de 1985, e o da plataforma em desenvolvimento, levando a uma solução que transformasse o primeiro numa especificação do segundo. A estreita relação e intensa troca entre a equipe de desenvolvimento do IPE e a RBTU, fonte acreditada do conhecimento específico sobre o domínio da formação de imagens em modo-B por ultrassom, permitiu a exploração direcionada

166 do domínio e a definição do escopo de desenvolvimento através da criação e simulação sobre modelos mentais, a exemplo do modelo mental sobre a natureza e física da formação de imagens modo-B por ultrassom pulso-eco, apresentado na figura 6.1.

Figura 6.1 - Modelo mental da natureza e física da formação de imagens modo-B

Fonte: Autoria própria

O modelo traz consigo inúmeras simplificações e premissas sobre o domínio do problema que servem ao propósito evidenciar as propriedades relevantes à formação da imagem modo-B, ignorando-se, por exemplo, a existência dos lóbulos laterais, do efeito de espalhamento do feixe, etc. Dentre as simplificações e premissas adotadas no modelo listam-se: • A onda transmitida (pulso ultrassônico) viaja ao longo de um caminho em linha reta do transdutor para o objeto e de volta para o transdutor. • As dimensões do feixe ultrassônico são desprezíveis, tanto na espessura da seção (elevação), quanto nas direções laterais. • A fator de atenuação da onda transmitida não varia no meio. • A onda de ultrassom viaja a uma velocidade constante de 1540m/s no tecido. De forma que a posição espacial do objeto é determinada pela diferença de tempo entre a transmissão do pulso e o retorno do eco correspondente (tempo de voo ou round-trip time).

167

• Todos os ecos detectados são originados apenas no eixo de propagação do feixe principal. • Todos os ecos detectados são derivados do último pulso transmitido. • Cada refletor/interface contribui com um único eco quando interrogado ao longo de um único feixe (scanline). • A amplitude do eco está relacionada tão somente à diferença das características acústicas do objeto irradiado e do meio. Além do modelo da física da formação de imagens modo-B por ultrassom pulso-eco, outros modelos foram criados durante essa atividade, a exemplo do modelo da conformação do feixe (beamforming) e do modelo do processamento e formação de imagens modo-B circa 1985, figura 6.2a e 6.2b respectivamente, abrangendo os aspectos específicos do domínio do problema pertinentes aos objetivos do projeto.

Figura 6.2 - Formação de imagens por ultrassom focalizado: a. Modelo da conformação do feixe (beamforming); b. Modelo da cadeia de processamento de sinais

168

Fonte: Autoria própria

As simulações sobre o conjunto de modelos mentais engendrados nessa etapa permitiram a extração de características particulares do sistema de interesse. Por exemplo, para as imagens modo-B capturadas em vídeo, não há uma correlação exata entre a taxa de atualização dos quadros no vídeo e a física da formação de imagens modo-B; a taxa de quadros no vídeo é fixado de acordo com o padrão televisivo empregado (por exemplo, 25Hz no padrão europeu e 30Hz no padrão americano), enquanto que a taxa limite para a formação de imagens modo- B depende de fatores como profundidade e o número de feixes empregados na formação da imagem (scanline). Esse conjunto de modelos mentais formara a base do conhecimento da equipe de desenvolvimento sobre o domínio específico, definindo a ontologia do domínio, os requisitos específicos e os constraints associados que cercearam e limitaram o escopo de desenvolvimento; elenca-se a seguir um subconjunto dos requisitos e constraints associados ao domínio da formação da imagem em modo-B por ultrassom pulso-eco aplicado ao desenvolvimento: • O sistema deve ser capaz de adquirir, processar e apresentar imagens modo- B em tempo real com taxa de atualização de quadros próxima dos 30Hz a uma profundidade de 20cm (máxima profundidade de aquisição). Considerando uma imagem modo-B formada por 128 feixes, com 20cm de profundidade, e velocidade de propagação do pulso ultrassônico no tecido de 1540m/s, o sistema deverá ser capaz de processar o feixe em seu tempo de voo, cerca de 260µs, a fim de garantir uma taxa de atualização aproximada de 30Hz. • O sistema deve ser capaz de apresentar imagens adquiridas de transdutores lineares, convexos e setoriais. Em outras palavras, o sistema deverá ser capaz de conformar e direcionar os feixes de transmissão e recepção, além de apresentar as imagens correspondentes a cada tipo de transdutor em sua conversão de varredura (scan conversion) apropriada.

169

• O sistema deve ser capaz de processar sinais na faixa de 1 a 10MHz. Limita a escolha dos transdutores aos disponíveis em 1980. • O sistema deve aplicar a técnica de atraso e soma de focalização do feixe de transmissão e recepção. Determina uma técnica particular de conformação do feixe ultrassônico de foco único comercialmente utilizada na década alvo (1980). • O sistema deve apresentar imagens com 256 níveis (8-bits) de cinza. Representação típica dos sistemas ultrassônicos dos idos de 1985. Já a exploração do domínio do problema relacionado à plataforma em desenvolvimento, enquanto fruto do esforço interno ao grupo de pesquisa do IPE, foi estabelecida pela interelações profissionais entre os engenheiros do grupo. Os engenheiros responsáveis pela arquitetura e design da plataforma, seus componentes de hardware, firmware e aplicativo PC, foram assinalados como fontes autorizadas de conhecimento e guiaram a prospecção do conhecimento relevante específico. O esboço preliminar da arquitetura, figura 6.3, do sistema serviu de gêneses dos modelos mentais e simulações elaboradas sobre o domínio.

170

Figura 6.3 - Esboço da arquitetura da plataforma de ultrassonografia diagnóstica

Fonte: Autoria própria

171

Das premissas adotadas sobre o domínio e características da plataforma, sumariza-se: • Pré-processamento adequado (AFE – front-end analógico): A plataforma contará com uma cadeia de pré-processamento de sinais compatível com as características únicas dos sinais ultrassônicos. • Geração de pulso adequada: A plataforma contará com um conjunto de canais de transmissão capaz de efetuar a conformação do feixe de transmissão, e gerar pulsos ultrassônicos com potência suficiente para seu uso diagnóstico e concordante com o processamento de recepção dos ecos detectados. • Processamento pipeline: A plataforma contará com uma arquitetura pipeline para o processamento back-end digital. • Plataforma de computação heterogênea: A plataforma é um sistema de computação heterogênea composto por FPGAs, DSPs e PC. • Configuração e sincronismo autônomos: A configuração e sincronismo dos módulos de transmissão e recepção e do processamento back-end digital será realizado autonomamente por uma estrutura dedicada na arquitetura da plataforma. A soma do universo de premissas e características sobre o domínio do problema relacionado à plataforma em desenvolvimento, governou e conduziu as estratégias e plano de desenvolvimento preliminar do back-end digital. A principal estratégia apontada para o projeto foi a utilização de técnicas e softwares de geração automática de código a partir de modelos. Motivado pela curta duração do projeto fontes (projeto USD), que previa o desenvolvimento da plataforma em um período de dezoito meses, pelo reduzido tamanho do time disponível para o desenvolvimento do back-end digital, e pelas incertezas que rondavam o desenvolvimento do proto85, a escolha da geração automática de código pretendia a redução do risco técnico envolvido, visto que, mesmo não sendo possível gerar código para uma tecnologia particular, os modelos seriam maduros o suficiente para sua transcrição numa linguagem ou noutra sem maiores dificuldades de entendimento e codificação. Outra motivação era a oportunidade de dominar uma

172 ou mais ferramentas para geração automática de código e incorporá-las ao arsenal técnico do time de desenvolvimento.

6.1.2 Modelagem conceitual

Das representações do domínio do problema da formação de imagem modo- B por ultrassom, foram derivados os cenários operacionais relacionados não só ao processamento back-end digital, mas ao sistema proto85, sua interação com os transdutores selecionados, com o usuário, em termos da parametrização e configuração da aquisição de imagens modo-B em tempo real, etc. Esses cenários foram utilizados para descrever o comportamento e operação da plataforma em desenvolvimento sob o viés do sistema proto85, considerando suas relações estímulo-resposta, generalizadas a fim de elidir qualquer solução definida a priori para o sistema. Sobre esses cenários operacionais foram aplicadas as representações do domínio do problema da plataforma em desenvolvimento, enquanto sistema de sistemas, extraindo os cenários operacionais e modelos conceituais relativo a cadeia de processamento back-end digital, figura 6.2b. Os cenários operacionais especificados para o back-end digital definem o sistema em dois momentos distintos: configuração e operação. Os cenários de configuração descrevem a parametrização do sistema considerando o sequenciamento empregado na plataforma. Em linhas gerais, não há parâmetro configurável durante a aquisição de imagens modo-B, consequentemente, qualquer que seja a mudança na configuração, há uma suspensão temporária da operação ou de qualquer interação com os sistemas adjuntos ao back-end, precedente a aplicação da configuração. Para cada configuração espera-se um comportamento específico do sistema durante sua operação, descritos individualmente nos cenários operacionais de configuração correspondentes. Por exemplo, a mudança do transdutor leva a mudança da imagem, que espelha a geometria da formação do feixe ultrassônico, que por sua vez é dependente das características e geometria do transdutor; a mudança distância focal deve alterar a resolução especial na região focalizada,

173 tornando-a mais nítida que a do restante da imagem; uma mudança na configuração da excursão dinâmica da imagem modo-B, altera a relação entre os ecos detectados de baixa amplitude e os de alta amplitude, tornando esses mais ou menos nítidos. Para os cenários de operação, e modelo conceitual, o sistema, bosquejado na figura 6.4, é reduzido a uma função de transferência, que tem como entrada o conjunto de ecos detectados para a formação da imagem modo-B, condicionados e digitalizados pelo front-end e como saída a imagem modo-B correspondente, implicando num sistema discreto com passo temporal igual ao tempo de captura do conjunto de ecos que formam a entrada, de forma que, em operação, o sistema pode ser expresso como um sistema: • Causal: A imagem modo-B só depende do conjunto de ecos capturados correspondentes. • Estável: As entradas e saídas quantizadas, de forma que toda entrada é limitada e dá origem a uma saída igualmente limitada. • Sem memória: A imagem resultante depende apenas dos ecos capturado no passo n. • Não-invertível: A imagem modo-B tem relação direta com a intensidade do sinal (módulo) não com sua amplitude, levando a uma relação não-invertível da função de transferência do sistema back-end. • Não-linear: O sistema não atende a propriedade de aditividade dos sistemas lineares. • Invariante no tempo: Uma vez que depende apenas do conjunto atual de ecos na entrada, a saída do sistema sofre a mesma translação temporal que sua entrada correspondente.

174

Figura 6.4 - Modelo conceitual do sistema

Fonte: Autoria própria

Dessa maneira, configurar ou parametrizar o sistema back-end – cenários operacionais de configuração – é alterar sua função de transferência para a operação posterior à aplicação da configuração, enquanto que a operação é reduzida a uma transformação direta. Cabe evidenciar que nesta simplificação, o sistema não toma ação e não reage a mudanças no meio ou em seus sistemas adjuntos durante a operação. Isto posto, falhas em qualquer de suas interfaces, entrada ou saída, não alteram a regra de transformação aplicada. Outro ponto particular que deve ser notado é que a técnica particular de beamforming, a ser implementado pelo back-end e requisito particular do sistema proto85, foi removido do modelo conceitual do back-end e transferido para o condicionamento presente no front-end, de forma que o conjunto de ecos detectados para a formação da imagem modo-B, entrada do modelo conceitual, é o conjunto de scanlines formadas pelo processo de beamforming, figuras 6.2b e 6.4. Mesmo fazendo parte do escopo de desenvolvimento do back-end digital, essa transferência do beamforming se deu sob o critério do sistema a ser definido versus a solução conhecida a priori. Desse esforço de especificação dos cenários operacionais e de modelagem conceitual, definiu-se os critérios técnicos do ambiente de simulação, enquanto que os objetivos do projeto, as estratégias de desenvolvimento, as análises de viabilidade e custo, as capacidades e expertises dos institutos envolvidos no desenvolvimento da plataforma, delinearam seus critérios não-técnicos. Alguns desses critérios são listados abaixo: • O ambiente deve ser permitir a simulação de todo o sistema proto85 e do meio, da transmissão do pulso, com um transdutor particular e foco

175

determinado, a interação do pulso com o meio, a detecção de ecos, o pré- processamento AFE e a geração de imagens modo-B. • O ambiente deve ser capaz de interagir com dados capturados por sistemas de aquisição de sinais ultrassônicos. • O ambiente deve ser capaz de mimetizar o comportamento pipeline previsto para a arquitetura da plataforma. • O ambiente deve permitir a integração de ferramentas para a geração automática de código a partir de modelos. • O ambiente deve possibilitar a visualização dos dados e sinais em qualquer etapa da geração da imagem modo-B, desde a transmissão do pulso até a imagem modo-B resultante. • O ambiente deve integrar, em sua maioria, ferramentas de modelagem já disponíveis nas instituições. Na análise de seus critérios e requisitos específicos, o ambiente de modelagem e simulação pôde ser completamente confinado ao par MATLAB®/Simulink® (The MathWorks Inc., Massachusetts, EUA). Dos principais fatores que levaram a escolha do par MATLAB/Simulink, listam-se: • A natureza dual do MATLAB, que é tanto ambiente de computação técnica e científica quanto uma linguagem de programação, o que possibilita o processamento, a análise e a visualização de dados, cálculos matemáticos, desenvolvimento de algoritmos, etc. • Possibilidade de modelagem de sistemas lineares e não-lineares modelados em tempo contínuo e/ou discreto, com partes amostradas ou atualizadas em taxas distintas através do Simulink. • Integração com o sistema de aquisição de sinais ultrassônicos SonixRP (Ultrasonix Medical Corp., Richmond, Canadá) através de um conjunto de ferramentas proprietário (SDK – Software Development Kit) para MATLAB. • Pacote de aplicação (toolbox) de simulação de campo acústico k-Wave (TREEBY; COX, 2010), acreditado pela RBTU e de vasto uso na comunidade científica, para MATLAB.

176

• Integração de toolboxes nativas para geração de código C/C++, VHD e Verilog, a partir de códigos MATLAB ou modelos Simulink. Das escolhas particulares dos componentes que compõem o entorno do ambiente de modelagem e simulação, foram as escolhas do sistema de aquisição de sinais ultrassônicos SonixRP e da toolbox de simulação de campo acústico k- Wave que mais impactaram positivamente o desenvolvimento do sistema proto85, em particular do back-end. Além da aquisição de um mesmo conjunto de ecos em diferentes pontos da cadeia de processamento, o sistema SonixRP possui um conjunto de ferramentas proprietário que permite não só a transferência dos dados capturados para o ambiente MATLAB, mas, através de sua interface de pesquisa e SDK MATLAB específico, configurar a aquisição dos sinais e processar os dados capturados, de forma a ser possível especificar completamente a transmissão e recepção do pulso ultrassônico, dentro dos limites do equipamento, e formar a imagem modo-B correspondente – ou, alternativamente, formar a imagem modo-B de um conjunto de dados com as mesmas características e formatação. Não obstante, o sistema SonixRP não se resume a um sistema de aquisição de sinais ultrassônicos com propósito de pesquisa, a exemplo do sistema OPEN System (Lecoeur Electronic Corp., Chuelles, França), sendo um equipamento médico certificado de ultrassonografia diagnóstica de uso geral, permite avaliar o desenvolvimento frente a um sistema diagnóstico legítimo. A escolha da toolbox k-Wave, em detrimento da escolha usual da toolbox Field II (JENSEN, 1996), provavelmente ainda a mais empregada das ferramentas para simulação de campo acústico com o propósito da ultrassonografia diagnóstica, ou de seu sucessor moderno, FOCUS (CHEN; MCGOUGH, 2008), sobreveio das limitações e premissas assumidas nestas ferramentas. Tanto no Field II quanto no FOCUS, assume-se que o meio de propagação consiste de um fundo homogêneo com dispersores (scatterers) pontuais, fornecendo apenas um modelo de atenuação com uma dependência linear com a frequência (modelo semianalítico), não sendo, portanto, uma escolha propícia para simulações envolvendo heterogeneidades ou propagações não lineares. Por sua vez, no k-Wave, é possível simular propagações não lineares em meios heterogêneos, permitindo uma distribuição arbitrária, em

177 uma, duas ou três dimensões, dos parâmetros de heterogeneidade do material (velocidade do som no meio, densidade, coeficiente de não-linearidade e atenuação). As funções em sua biblioteca incluem a capacidade de modelar fontes de pressão e velocidade, fontes fotoacústicas, além de superfícies de detecção arbitrárias com a opção de registro da pressão acústica, velocidade da partícula e da intensidade acústica. Desta forma, entender a ferramenta k-Wave acarreta num domínio/compreensão maior da física da propagação de ondas mecânicas e permite sua aplicação em contextos mais abrangentes, diferentes da ultrassonografia diagnóstica. Os cenários conceituais e workbench de validação foram criados a partir da aquisição de sinais e imagens modo-B sobre um phantom multi-tecido de propósito geral CIRS 040 (CIRS Corp., Virginia, EUA), através do sistema SonixRP, e das simulações sobre uma emulação do mesmo phantom, sob as mesmas condições de aquisição usando do k-Wave.

6.1.3 Modelagem sistêmica e do sistema-solução

Por se tratar de um sistema bem definido, numa tecnologia pré-concebida, não havia muito espaço para diferentes sistemas candidatos ou mesmo soluções alternativas para a cadeia de processamento do back-end digital, que, invariavelmente, assemelha-se àquela apresentada na figura 6.2b. Assim, poder- se-ia apenas considerar a cadeia de processamento tal qual descrita na literatura, suprimindo a etapa de modelagem sistêmica e partindo direto para as fases de design e implementação. Estratégia que, caso adotada, culminaria num abismo de conhecimento e rastreabilidade – um atalho que certamente poria em risco o empreendimento da pesquisa. Em oposição, buscou-se aprofundar-se na modelagem sistêmica e na decomposição top-down do sistema em macro-funções, desconsiderando, num primeiro momento, cadeias de processamento ou arquiteturas descritas em literatura. Neste contexto, aplicou-se o framework Function-Behavior-Structure (FBS) situado (GERO; KANNENGIESSER, 2014) sobre o SOI com o objetivo de decompô-

178 lo em um conjunto coerente de macro-funções. A ontologia FBS fornece ferramentas para entender o processo de design, enquanto o framework fornece ferramentas para entender o design e os processos não diretamente ligados a este, a exemplo do processo de como os designers constroem affordances – na definição de Norman (2013) – do objeto ou sistema projetado. A fim de tornar o processo de design aplicado ao caso de estudo transparente, e, considerando que seu produto (back-end digital) não é o alvo da análise, mas sim o processo de produzi-lo, cabe aqui uma descrição aprofundada do framework aplicado sob o contexto do processo ARES.

6.1.3.1 Framework FBS situado

A ontologia FBS retrata objetos de design em três categorias: função (F), comportamento (B) e estrutura (S). Função descreve a teleologia do sistema (ERDEN et al., 2008) – para que serve o sistema –, sendo atribuído ao sistema estabelecendo-se uma ligação entre seus objetivos e efeitos mensuráveis, numa relação entrada-saída. O comportamento descreve como o sistema realiza cada tarefa requerida pelas funções do sistema – o que o sistema faz –, definindo-se como os atributos do sistema que podem ser derivados de sua estrutura. Já a estrutura descreve os componentes sistema e suas relações – em que consiste o sistema –, reduzindo o sistema a entidades e componentes que interagem entre si para obter funções que podem ser capturadas a partir da visão de comportamento. O framework FBS, originalmente publicado por Gero em 1990, no artigo intitulado Design Prototypes: A Knowledge Representation Schema for Design, é uma extensão da ontologia FBS para representar o processo de design como um conjunto de transformações entre as categorias ontológicas. A visão mais básica do design consiste em transformar função em comportamento, F → B, e comportamento em estrutura, B → S. Nesse framework, o comportamento é interpretado como o desempenho esperado para alcançar a função desejada (Be). No entanto, uma vez que uma estrutura é produzida, deve-se verificar se o desempenho “real” do artefato,

179 baseado na estrutura produzida e no ambiente operacional, corresponde ao comportamento esperado, distinguido o comportamento derivado da estrutura (Bs) daquele esperado pela função (Be). Estendendo o conjunto de transformações com as quais pode-se descrever o design em: F → Be; Be → S; S → Bs e Be ↔ Bs (correspondente a comparação entre Be e Bs). Sob a consideração do processo de design em si, o framework introduz duas noções particulares, requisitos (R) e descrição de design (D), incluindo o requisito na noção de função e a descrição de design como a representação externa de uma solução de design particular: R → F; S → D. O framework adiciona ainda as transformações S → S, S → Be e S → F (via Be), com base na observação de que o design não é apenas um processo de desenvolvimento iterativo e incremental, mas frequentemente envolve mudanças de foco, pensamento lateral e ideais emergentes, assumindo que estruturas existentes possam gerar mudanças nas funções, comportamento ou mesmo estruturas do sistema. O framework FBS situado (sFBS) foi desenvolvido em 2000 como uma extensão do framework FBS para incluir a noção de situabilidade (GERO; KANNENGIESSER; 2014), baseando-se na ideia de que o design situado envolve a interação entre três mundo: o mundo externo, o mundo interpretado e o mundo esperado. • O mundo externo é o mundo composto das coisas externas ao designer, não importando se essas coisas são “reais” ou abstrações do objeto do design. • O mundo interpretado é a representação interna da parte do mundo externo com a qual o designer interage. O mundo interpretado fornece um ambiente para atividades analíticas e descobertas durante o design. • O mundo esperado é o ambiente no qual os efeitos das ações são previstos de acordo com os objetivos e propósitos e interpretações do estado atual do mundo/design. Esses três mundos são relacionados juntos por três classes de interações: Interpretação, que transforma variáveis que são percebidas no mundo externo em percepções, noções e conceitos que compõem o mundo interpretado; focalização, que leva alguns aspectos do mundo interpretado e usa-os como objetivos para o

180 mundo esperado, e; ações que são os efeitos que provocam mudanças no mundo externo de acordo com os objetivos e propósitos do mundo esperado. O conjunto de representações de design esperado corresponde à noção de um espaço de estados de design, isto é, o espaço de estados de todos os designs possíveis que satisfazem o conjunto de requisitos. Esse espaço de estados pode ser modificado durante o processo de design, transferindo novas representações de design (mundo interpretado) para o mundo esperado e/ou transferindo algumas das representações para fora do mundo esperado, levando a mudanças nas representações de design do mundo externo, que podem então ser usadas como base para a reinterpretação que altera o mundo interpretado. Novas interpretações podem ainda ser resultado de memória construtiva, as quais podem ser vistas como um processo de interação entre representações do mundo interpretado. Gero e Kannengiesser (2014) combinaram a ontologia e o framework FBS com o modelo de mundos interativos descrito acima, especializando o modelo de contextualização pela aplicação das três categorias ontológicas – função, comportamento e estrutura – na representação do design; base do framework FBS situado, resumido na figura 6.5. Além do uso de funções, comportamentos e estruturas externos (Fe, Be e Se), interpretados (Fi, Bi e Si) e esperados (Fei, Bei e Sei), neste framework usa-se representações explícitas de requisitos externos de função (FRe), de comportamento (BRe) e de estrutura (SRe). O framework FBS situado introduz ainda o processo de comparação entre comportamentos interpretados e esperados, Bi ↔ Bei, e um número de processos que transformam estruturas interpretadas em comportamentos interpretados, Si → Bi, comportamentos interpretados em funções interpretadas, Bi → Fi, funções esperadas em comportamentos esperados, Fei → Bei, e comportamentos esperados em estruturas esperadas, Bei → Sei.

181

Figura 6.5 - Framework FBS situado

Fonte: GERO; KANNENGIESSER, 2014 (Reproduzido com autorização)

Os vinte processos indicados no framework são mapeados nos oito processos fundamentais do framework FBS original: Formulação, síntese, análise, avaliação, documentação, reformulação tipo 1, reformulação tipo 2 e reformulação tipo 3.

182

Formulação – processos de 1 a 10: A formulação enquadra a tarefa de design definindo um espaço de estados de possíveis soluções de design (espaço de estados de estrutura), e um conjunto de critérios para avaliar essas soluções (espaço de estados de comportamento). Essa atividade usa como entrada um conjunto de requisitos, objetivos e propósitos (espaço de estados de função) e constraint fornecido ao designer por especificações externas ou com base em sua própria experiência. Esses requisitos são interpretados, produzindo Fi, Bi e Si (processos 1, 2 e 3) que, por sua vez, são complementados com requisitos implícitos construídos a partir da memória do designer (processos 4, 5 e 6). Os processos 7, 8 e 9 representam a decisão sobre um conjunto de requisitos para formar o espaço de estados de design. O processo 10 captura como comportamentos esperados (Bei) adicionais são derivados das funções esperadas (Fei). Síntese – processos 11 e 12: Síntese instancia uma solução de design em termos de um ponto no espaço de estados de estrutura. O designer produz um design decidindo sobre valores das variáveis da estrutura formulada (processo 11). O design é então externalizado (processo 12) como modelo computacional, protótipo físico, etc. Análise – processos 13 e 14: Análise deriva o comportamento da solução de design. O designer usa uma série de cálculos, simulações, modelos e testes de protótipos físicos para analisar a solução de design, o que requer interpretação da estrutura externa (processo 13). O comportamento pode então ser derivado (processo 14) usando uma (ou mais) das três abordagens: • Por computação – através de ferramentas computacionais especializadas usadas para executar cálculos complexos e simulações. • Pela medição física – através dos efeitos físicos, elétricos, químicos, etc., causados pela interação de dispositivos de medição e protótipos físicos. • Pelo raciocínio humano – usado geralmente em combinação com métodos computacionais ou medições físicas. Avaliação – processo 15: avalia a solução de design com base nos critérios formulados, i.e., através da comparação do comportamento derivado do design e

183 de seu comportamento esperado. Com base no resultado dessa comparação, o designer decide se a solução proposta atende aos requisitos. Por vezes, o design passa por mudanças que levam a novos ciclos de síntese, análise e avaliação. Documentação – processos 12, 17 e 18: A documentação produz uma representação externa de uma solução de design para fins de comunicação e registro. Ao fim de um processo de avaliação bem-sucedido, um conjunto de artefatos, desenhos e modelos são produzidos, incluindo os componentes e partes individuais do sistema (processo 12). Um número de diagramas que documentam alguns dos comportamentos também são gerados (processo 17), e algumas funções são documentadas para fins de indexação, registro, marketing ou explicação de decisões de design (processo 18). Reformulação tipo 1 – processo 9: reformula o espaço de estados da estrutura, criando um novo espaço de designs possíveis, o que, geralmente, envolve uma modificação subsequente do espaço de estados do comportamento. Reformulação tipo 1 é impulsionada pelos processos 3, 6 e 13, visto que estes processos têm o potencial de produzir novas estruturas. Reformulação tipo 2 – processo 8: reformula o espaço de estados de comportamento. Na maioria dos casos, isso leva a uma modificação do espaço de estados de estrutura e, portanto, à criação de um novo espaço de designs possíveis. Os processos 2, 5, 14 e 19 são os impulsionadores potenciais desse tipo de reformulação. Reformulação tipo 3 – processo 7: reformula o espaço de estados de função, o que, geralmente, leva a uma modificação dos espaços de estados de comportamento e de estrutura e, portanto, à criação de um novo espaço de designs possíveis. Os processos 1, 4, 16 e 20 são os impulsionadores da reformulação tipo 3.

184

6.1.3.2 O resultado da modelagem sistêmica e do sistema-solução e a estrutura ontológica do catálogo de soluções

Com o propósito único de demonstrar a aptidão da plataforma tecnológica desenvolvida no projeto raiz para a formação, aquisição, processamento e apresentação de imagens diagnósticas por ultrassom em tempo real, o sistema candidato escolhido para o back-end digital foi a própria cadeia de formação de imagens modo-B. Pode-se pensar, a princípio, que não há outro sistema candidato senão a cadeia de processamento em si, entretanto, um sistema candidato possível pode ser tal que permita, sem prejuízo ao sistema, a troca entre blocos ou etapas do processamento, ou ainda que possibilite/antecipe a adição de outros modos de imagens ou técnicas. O sistema back-end candidato, tal como concebido, é descartável e espelha as restrições de recursos do projeto, ao mesmo passo em que reduz os riscos envolvidos com o ineditismo deste tipo de empreendimento e parceria tanto para o IPE quanto para a RBTU. Na aplicação do framework sFBS, restringida às fronteiras da modelagem do sistema-solução (conjunto de atividades descrito no Capítulo 5, Seção 5.2.3), os modelos e cenários conceituais do sistema compõem tanto os requisitos no mundo externo quanto as funções, comportamentos e estruturas no mundo esperado. Essa estrutura cíclica permite a revisão dos modelos conceituais e de seus requisitos sob a ótica do desenvolvimento e especificação do sistema-solução. Com o desígnio de trazer racionalidade e uniformidade à decomposição do sistema, propôs-se adotar um paradigma único, construído sob o conceito de transformação da informação (FERNANDES; ONISTO, 2018), capaz de expor, sob uma mesma perspectiva, cada componente do sistema. Na figura 6.6 exibe-se o resultado da decomposição do sistema em suas macro-funções (modelo em “caixa cinza”), aplicado ao front-end e ao back-end.

185

Figura 6.6 - Modelo em "caixa cinza": Decomposição do sistema em suas macro-funções

Fonte: Autoria própria

186

O processo de decomposição do sistema, detalhado no artigo Component- Based System Design Guided by an Apparent-Ontology: A Case Study in Ultrasound Imaging (FERNANDES; ONISTO, 2018) 7 , e extrapolado para as demais modalidades de imagens ultrassônicas, resultou numa estrutura hierárquica do processamento de sinais ultrassônicos (catálogo das soluções aplicáveis para cada macro-função), esquematizada na figura 6.7. Essa estrutura representa o mundo externo do framework sFBS, onde a transformação da informação que constitui o modo de imagem representa Fe, Be é representado pelas macro-funções (transformações unitárias) e Se pelas abstrações matemáticas que resolvem e implementam as transformações unitárias.

7 Disponível em http://www.iiis.org/CDs2018/CD2018Spring/papers/ZA501KG.pdf

187

Figura 6.7 - Estrutura ontológica do catálogo de soluções

Fonte: Autoria própria

188

Nessa abordagem, define-se um modo de imagem pela sua informação primária, que pode ser uma propriedade ou característica única de um sinal ou dado, ou pela maneira como essa informação é processada e exibida. Por conseguinte: • Uma CLASSE é um conjunto de MODOS que usam a mesma informação primária. • Um MODO é um modo de imagem que usa uma, e apenas uma, informação primária. Desta forma, o modo duplex não constitui um modo em si, mas a composição de dois modos distintos, o modo-B e o modo Doppler colorido. Da mesma arte, define-se o conceito de modo clone como o modo de imagem que usa, processa e apresenta uma informação primária da mesma forma que um outro modo, a exemplo do modo de ultrassonografia contrastada, clone do modo-B. • Uma FAMÍLIA descreve um estágio (módulo) na cadeia de processamento de um MODO particular, a exemplo da detecção de envelope na imagem modo-B. • Uma TÉCNICA é um princípio de solução que resolve a transformação da informação/dado de um módulo. A detecção de envelope pode ser resolvida aplicando-se tanto o princípio de extração da amplitude instantânea, quanto o da extração de contorno, cada uma com sua estrutura e relação matemática própria. • Uma ABSTRAÇÃO é um modelo de alto-nível que descreve um ou múltiplas maneiras de implementar uma TÉCNICA. Para a extração da amplitude instantânea, princípio de solução para a detecção de envelope, que considera a representação analítica do sinal, a demodulação em fase e em quadratura (I/Q) ou a transformada de Hilbert são abstrações possíveis para sua implementação. Para cada ABSTRAÇÃO existe pelo menos um ALGORITMO que a implementa e especifica um conjunto de parâmetros, entradas e saída, constraints e propriedades não-funcionais. Para a composição do sistema-solução (back-end digital), cujo diagrama lógico pode ser visto na figura 6.8, optou-se pelas abstrações do catálogo de soluções aplicáveis que, pelo crivo da RBTU, melhor representariam a cadeia de

189 processamento típica dos primeiros equipamentos computadorizados de ultrassonografia, a saber: Detecção de envelope: Uso da técnica de extração da amplitude instantânea do sinal analítico através da demodulação I/Q. Mapeamento da magnitude: Técnica de reescalonamento do sinal com o uso de compressão não-linear, no caso particular compressão logarítmica. Melhoria de atributos do sinal: Aplicação da técnica de homogeneização de estruturas através do uso de filtro espacial da mediana. Scan conversion: Mapeamento espacial da posição relativa da aquisição para um frame de dimensões definidas, com o uso da transformação de coordenadas e interpolação.

190

Figura 6.8 - Diagrama lógico do sistema-solução

Fonte: Autoria própria

191

Com a definição do sistema em “caixa branca”, os cenários conceituais foram encapsulados, em ambiente MATLAB, em cenários executáveis. O fato de ambos, cenários conceituais e executáveis, serem compreendidos completamente no mesmo ambiente MATLAB, permitiu que uma correlação um para um entre eles fosse feita, o que possibilitou a análise direta dos resultados da validação do sistema-solução. A validação em si deu-se majoritariamente pela análise bloco a bloco da transformação realizada sobre o sinal, através de peer-reviewing e comparação com os resultados obtidos com o sistema comercial SonixRP. Cada macro-função, confinada num subsistema, configura, em si, o workbench de verificação e interoperabilidade. Para cada cenário executável, a relação entrada-saída de cada subsistema é mapeada de forma que, para cada etapa posterior do desenvolvimento, um modelo de menor granularidade substituirá sua macro-função correspondente no cenário executável apropriado e terá seu resultado comparado com a relação entrada-saída mapeada. Por se tratar de um modelo sobre modelo, num mesmo ambiente de simulação, a validação e verificação são regressivas e acessíveis aos especialistas de domínio, sendo o aval destes o critério de verificação e validação. Sob o prisma da gestão do conhecimento, a decomposição do sistema numa perspectiva top-down e a estrutura ontológica do catálogo de soluções, facultou na revisão da literatura especializada, e na crítica de seus preceitos, tendo como exemplo: • O desacoplamento do beamforming da técnica de supressão de lóbulos laterais, permitiu distinguir e classificar técnicas particulares descritas na literatura sob o aspecto da transformação aplicada sobre o sinal. Tomando a técnica de beamforming de mínima variância como exemplo, no contexto da transformação da informação, esta não se trata de um beamforming propriamente, mas de uma técnica adaptativa de supressão de lóbulos laterais e pode ser efetivamente aplicada a qualquer técnica de beamforming. • Com relação a compressão logarítmica, abstração não linear do mapeamento da magnitude, há uma aparente negligência quando a sua descrição na literatura que, de maneira descuidada, prover diversas

192

explicações para seu propósito e uso. Alguns autores argumentam que seu uso se dá pela necessidade de reduzir a excursão dinâmica do sinal ultrassônico para algo entre trinta e sessenta decibéis, que afirmam ser o compatível com a visão humana (AKKALA et al., 2014; CHEN, 2016). Outros afirmam que não é com o aparato visual humano que o sinal deve ter compatibilidade quanto a sua excursão dinâmica, mas aos monitores e telas (KLEIN, 2012; XIAO et al., 2018). Ambas visões, e tantas outras, como a necessidade de mapear o sinal para sete ou oito bits, conformar a distribuição estatística do sinal, etc., não justificam o mapeamento em função logarítmica, tampouco elucidam seu propósito. No contexto da transformação da informação, o mapeamento da magnitude realiza uma mudança de domínio, convertendo do domínio do sinal para o domínio da imagem. Desta forma o propósito do mapeamento de magnitude é permitir uma melhor análise e interpretação visual da informação contida no sinal ultrassônico, o que, por si, esclarece o uso de uma função logarítmica no mapeamento, uma vez que a escala logarítmica a que melhor expressa a relação estímulo/percepção, lei de Weber-Fechner (FECHNER, 1966), do aparato visual humano a uma distância moderada, permitindo a apreciação de sinais de menor e maior intensidade numa mesma imagem.

6.1.4 Arquitetura, design e implementação do sistema8

O propósito do projeto Proto85, no qual se insere o desenvolvimento do sistema back-end digital, é demonstrar a aptidão da plataforma tecnológica desenvolvida no projeto USD para a formação, aquisição, processamento e apresentação, em tempo real, de imagens diagnósticas por ultrassom. Dito isto, é a plataforma desenvolvida, a tecnologia aplicável ao sistema-solução, e sua arquitetura, a arquitetura do sistema.

8 Esta seção apresenta o framework para particionamento, adequação e geração automática de código a partir de modelos MATLAB/Simulink desenvolvido no Instituto de Pesquisas Eldorado, cuja expressa autorização para sua divulgação encontra-se no ANEXO A.

193

A porção da plataforma reservada ao back-end digital conta com os blocos DSP, Concentradora e RX (Figura 6.3). A seguir listam-se as principais características das tecnologias empregadas nessa porção particular do sistema relevantes ao desenvolvimento da cadeia de processamento digital do sinal ultrassônico. • A implementação do bloco DSP realizada por um processador digital de sinais TMS320C6678 (Texas Instrument Inc., Dalas, EUA), enquanto que os blocos RX e Concentradora foram implementados por FPGAs (Field Programmable Gate Array) da família Virtex-6 (Xilinx Inc., São José, EUA). • Comunicação entre FPGAs (módulos Concentradora, RX e TX) através da interface Aurora 64B/66B (Xilinx Inc., São José, EUA). • Comunicação entre os blocos DSP e Concentradora implementado pelo protocolo EMIF16 (Texas Instrument Inc., Dalas, EUA), uma interface de memória externa utilizando um barramento de 16 bits. • Interface Gigabit Ethernet entre DSP e PC. • A plataforma opera em 64 canais, para transmissão e recepção de sinais ultrassônicos, expansíveis para 128, tendo como ponto convergente, onde os dados são concatenados, o módulo Concentradora. Desta forma, a expansão para 128 canais ocorre com a inserção de um novo par de módulos TX e de um módulo RX, mantendo o restante do sistema inalterado. • A plataforma possui característica modular e cada bloco e componente constituinte pode ser substituído ou modificado sem prejuízo ao sistema. • O sistema foi concebido numa arquitetura pipeline. Antes de prosseguir para o design e implementação do back-end, cabe a análise sobre algumas das características das tecnologias e técnicas listadas acima. A primeira é a consideração sobre a estratégia pipeline, diagramada na figura 6.9, onde T1...T5 são tasks (tarefas) e S1...S4 são segmentos.

194

Figura 6.9 - Estratégia Pipeline

Fonte: Autoria própria

O processamento pipeline é uma técnica de implementação na qual as suboperações aritméticas (pipeline aritmético) ou as fases de um ciclo de instrução (pipeline de instrução) se sobrepõem na execução. Destarte, presume-se que o processamento back-end possa ser decomposto em uma sequência de suboperações que serão executadas simultaneamente em segmentos parcialmente dedicados. Outra consideração é sobre as FPGAs da família Virtex-6, tecnologia aplicada aos blocos Concentradora e RX. De maneira geral, uma FPGA é um circuito integrado que pode ser programado, após sua fabricação, para operar como qualquer circuito digital desejado pelo designer. Os principais blocos que constituem FPGAs modernas, a exemplo da família Virtex-6 da Xilinx, são blocos lógicos configuráveis (CLB, do inglês, Configurable Logic Block), interconexões, blocos entrada/saída (I/O), e blocos rígidos embarcados, a exemplo de blocos RAM (BRAM) e DSP (DSP48E1). Uma visão geral da arquitetura e blocos das FPGAs da família Virtex-6 é mostrada na figura 6.10.

195

Figura 6.10 - Arquitetura geral das FPGAs Virtex-6: a. Distribuição dos blocos básicos; b. Bloco rígido DSP48E1; c. Blocos lógicos programáveis; e, d. Estrutura interna de uma Célula lógica

Fonte: XILINX, 2011; 2012

196

O CLB é principal recurso lógico para implementar circuitos digitais combinacionais e sequenciais nas FPGAs da família Virtex-6 (XILINX, 2012). Cada CLB tem dois slices, cada um com carry logic (lógica “vai-um”) e quatro células lógicas (LC, do inglês, Logic Cell), designados como A, B, C e D, com LUTs de seis entradas e dois elementos de armazenamento de um bit (flip-flop) cada; parcialmente representado nas figuras 6.10b e 6.10d. Cada LUT de seis entradas é composta por duas LUTs de cinco entradas e um multiplexador 2 para 1, caracterizando uma LUT fraturável (K6, M5)-FLUT (DICKIN; SHANNON, 2011). Além disso, alguns slices suportam duas funções adicionais: armazenar dados usando RAM distribuída de 64 bits e transferir dados com registros de 32 bits (shift register). Na família Virtex-6 um slice DSP consiste de um pré-somador, um multiplicador de 25x18 bits seguido por uma unidade lógica e aritmética (ALU, do inglês, Arithmetic Logic Unit). A primitiva DSP48E1 (XILINX, 2011), cuja a representação simplificada pode ser vista na figura 6.10b, suporta as mais diversas funções, incluindo adicionar-multiplicar, multiplicar, multiplicar-acumular, multiplicar- adicionar, somador de três variáveis, etc. Além de capacidade de armazenamento de dados diretamente, os blocos BRAMs podem ser acessados por meio de duas portas independentemente, permitindo que, no mesmo ciclo de máquina, dois endereços possam ser lidos ou escritos. Além de contar com estruturas auxiliares que permite a criação de FIFOs (First In, First Out) e buffers circulares. Por fim cabe considerar o TMS320C6678 (referido como C6678 no restante do texto) da Texas Instrument (TI), tecnologia aplicada ao bloco DSP. O C6678 (TEXAS, 2010a) trata-se de um processador multicore homogêneo capaz de suportar operações aritméticas em ponto fixo e/ou flutuante. Este dispositivo em particular contém oito núcleos C66x, esquematizado na figura 6.11, fornecendo 128 GFLOPS (bilhões de operações de ponto flutuante por segundo) de precisão simples (SP, do inglês, single precision), e 32 GFLOPS de precisão dupla (DP, do inglês, double precision), quando operando a 1GHz.

197

Figura 6.11 - Diagrama de blocos de núcleo DSP C66x

Fonte: ALI et al., 2012

Os núcleos C66x são máquinas VLIW (do inglês, Very Long Instruction Word) de 8 vias capaz de expedir oito instruções paralelas em cada ciclo (TEXAS, 2010c). Cada núcleo é composto de dois blocos conhecidos como Datapath A e B. Cada bloco conta com um banco de registros contendo 32 registrados de uso geral de 32 bits e quatro unidades de execução que podem operar em paralelo, a saber: unidade lógica .L, unidade multiplicadora .M, unidade de deslocamento .S e unidade de dados .D. Os Datapath contam ainda com múltiplos caminhos para 1)

198 comunicação de dados entre cada bloco e a memória, 2) comunicações de dados dentro de um bloco ou 3) comunicação de dados entre blocos (DAHNOUN, 2018). As unidades .L suportam até operandos de 64 bits, completando cada instrução em um ciclo. Estas unidades podem executar: • Operações aritméticas em ponto flutuante e/ou fixo • Operações lógicas • Funções de ramificação (branch) • Operações de empacotamento de dados (data-packing) • Conversão de/para valores inteiros e de precisão simples As unidades .L possuem instruções adicionais para lógicas AND e OR, bem como rotação de 90 ou 270 graus de números complexos (TEXAS, 2010b). As unidades .M são unidades multiplicadoras em hardware que podem executar multiplicações de ponto fixo ou flutuantes de até 128 bits. As unidades .S contêm ALUs inteiras de 32 bits e deslocadores (shifters) de 40 bits, podendo ser usadas para: • Operações aritméticas, lógicas e de campo de bits (bit field) de 32 bits • Shift de 32/40 bits • Ramos (branches) • Transferir de/para registros de controle (.S2 apenas) • Geração de contantes As unidades .D são as únicas unidades que podem ser usadas para acessar a memória, sendo usada nas seguintes operações: • Carregar e armazenar dados com offset constante de 5 bits • Carregar e armazenar dados com offset constante de 15 bits (.D2 apenas) • Adições e subtrações de 32 bits • Cálculos de endereço linear e circular • Operações lógicas • Mover uma constante ou dados de um registrador para outro. Os oitos núcleos do C6678 permitem que o sistema aproveite o paralelismo no nível dos threads executando diferentes threads em diferentes núcleos. Há 32kb de memória L1 de programa (L1P) e de dados (L1D), e 512kb de memória L2

199 dedicados para cada núcleo (Figura 6.11). A memória de dados L1 e a memória L2 podem ser configurados como RAM e ou cache. Há um adicional de 4Mb de memória compartilhada no chip acessível por todos os núcleos, uma interface de memória DDR3 externa de 64 bits (1600MHz) e suporte para DRAM ECC (do inglês, Error-Correcting Code Dynamic-RAM) (TEXAS, 2010c). A arquitetura em pipeline da plataforma não goza do paralelismo, expresso na lei de Amdahl (AMDAHL, 1967), da arquitetura multicore do C6678. De maneira diversa, a arquitetura faz uso sequencial dos núcleos do DSP, reservando dois núcleos para o processamento back-end: um dedicado ao processamento em linhas e o outro ao processamento matricial aplicado sobre a imagem ou frame adquirido. Os DSPs da TI, o C6678 incluso, executam um sistema operacional nativo em tempo real chamado SYS/BIOS. Um compilador C/C++, compatível com C89/C++98, é fornecido como parte do ambiente de desenvolvimento, chamado CCS (do inglês, Code Composer Studio). Para melhorar a eficiência do código gerado para cada arquitetura da TI, o compilador fornece técnicas de otimização na forma de pragmas e instruções SIMD (do inglês, Single Instruction Multiple Data) intrínsecas para explorar completamente a arquitetura do núcleo e extrair todo o desempenho potencial sem recorrer à programação assembly (DAHNOUN, 2018).

6.1.4.1 Modelo da abstração de tecnologia

Adotoram-se algumas estratégias sobre o design e implementação do processamento back-end digital que nortearam o processo de particionamento e a construção dos modelos encapsulados e de implementação. A principal e mais restritiva dentre essas estratégias é o uso do toolset de geração automática de código da MathWorks para a criação dos modelos de implementação para as macro-funções presentes na cadeia de processamento back-end. Isso implica que todo o processo de design será realizado em ambiente MATLAB e que qualquer alteração num IM deverá ser feita em seu modelo encapsulado correspondente, de forma que não haja quaisquer alterações manuais no código gerado (IM). Outra implicação é que o encapsulamento deverá conter uma etapa de processamento

200 completa, por exemplo, o oscilador local não poderá ser dissociado da demodulação I/Q no encapsulamento e geração de código, porém é possível dissociar esta da extração da magnitude instantânea. O particionamento do sistema deve ainda considerar as características particulares das tecnologias e arquitetura da plataforma desenvolvida, reduzida ao uso particular do projeto Proto85 na figura 6.12, e do processamento front-end dentre as quais destacam-se: • A expansibilidade da plataforma impõe ao módulo RX a realização tão somente de transformações lineares sobre o sinal. • As características do front-end e da técnica de beamforming escolhida, somadas ao processamento pipeline, impõem aos segmentos que operam sobre as amostras (individualmente) tempo máxima de execução de 12.5ns (80MHz). A não consideração dessa constraint pode ocasionar num conflito de dependência de dados, no qual uma suboperação depende do resultado ainda não disponibilizado pela suboperação anterior. Cabe ainda considerar a representação dos dados e taxa de transferência entre o front-end e back- end, que, considerando uma taxa de atualização de frames de 30 fps com profundidade máxima de 20 cm e amostras de 16 bits, é superior a 1 Gb/s. • As interfaces entre as tecnologias e as representações dos pacotes de dados trocados entre elas restringem a compatibilidade de uma ou mais etapas do processamento back-end com a tecnologia alvo. Das estruturas definidas na plataforma, são as interfaces entre Concentradora e DSP e entre DSP e PC as mais impactam sobre o particionamento e encapsulamento das macro- funções. A Concentradora enviará ao DSP um buffer contendo o processamento em FPGA da scanline correspondente em representação de 16 bits. Já o DSP transferirá entre o núcleo dedicado ao processamento em linha e o núcleo dedicado ao processamento matricial, um vetor ordenado de linhas sequenciais em representação de 8 bits sem sinal. Por fim será transferido ao PC um frame com resolução de 480x640 pixels. • A taxa de transferência de dados entre as diferentes etapas do processamento back-end, bem como as características de cada macro-

201 função em sua cadeia, restringe a compatibilidade de uma etapa com a tecnologia proposta para sua alocação.

202

Figura 6.12 - Diagrama da arquitetura da plataforma

Fonte: Autoria própria

203

De maneira geral a modelagem da abstração de tecnologia foi favorecida pela escolha do ambiente de modelagem e simulação Simulink. Diagramas de blocos no Simulink definem relações baseadas em tempo entre sinais e variáveis de estado. A solução de um diagrama de bloco é obtida avaliando esses relacionamentos ao longo do tempo em intervalos (time step). Em outras palavras, um diagrama de blocos representa, a cada passo de tempo, o comportamento instantâneo de um sistema dinâmico, de forma que, para cada bloco no diagrama (em modelo de topo), as saídas são calculadas e estarão disponíveis para os demais blocos no passo tempo subsequente; uma estrutura similar à arquitetura em pipeline. Do modelo da abstração de tecnologia, duas outras considerações sobre a representação dos tipos e dados empregados nas tecnologias se fazem relevantes ao processo de design e implementação: 1) a representação de matrizes como vetores de linhas sequencialmente ordenadas no DSP e 2) a abstração das LUTs como funções booleanas com até seis entradas nas FPGAs.

6.1.4.2 Particionamento, encapsulamento e implementação

A primeira proposta de particionamento do sistema considerava o melhor das capacidades de processamento de cada tecnologia, dessa maneira, caberia à FPGA apenas a demodulação do sinal em suas componentes em-fase, 퐼 , e quadratura, 푄 , e ao DSP as demais etapas do processamento (Figura 6.8). Entretanto, durante o processo de verificação da implementação do demodulador, com técnicas de hardware-in-loop, apurou-se que a interface EMIF16 entre Concentradora e DSP não suportava o intenso fluxo de dados, limitando o sistema a um dezesseis avos de sua taxa nativa de 80MHz (considerando as duas componentes I/Q e o cenário de pior caso). Esta limitação impunha à interface uma decimação dos dados processados nas FPGAs, e, mais que isso, que o sinal decimado mantivesse suas informações de banda base. Desta forma, uma segunda proposta de particionamento foi feita. Nela, toda a detecção de envelope ficaria a cargo das FPGAs, com a demodulação nas RXs e a detecção da magnitude

204 instantânea na Concentrada, adicionado a um concatenador integrado ao pipeline, que soma coerentemente os dados das RXs (no caso da expansão para 128 canais), e de um decimador com um fator de 10, que tornar a cadeia de processamento em pipeline compatível com a interface. Demodulação I/Q, concatenação e decimação (Detecção de envelope) Pode-se entender de uma scanline como uma senóide alternada (com valor médio igual a zero e amplitude variando entre valores positivos e negativos) cuja amplitude e fase mudam em função do tempo. A variação da amplitude é proporcional a quantidade de reflexão e retrodifusão da onda acústica no meio numa dada profundidade. A demodulação I/Q, similar à demodulação AM em telecomunicação, é capaz de extrair a informação da amplitude, com a vantagem de reduzir a quantidade de dados, transferindo o sinal para a banda-base. Na demodulação I/Q o sinal recebido (scanline) é multiplicado com a

−푖휔푇푋푡 exponencial complexa 푒 , o que desloca seu espectro de frequência em 푓푇푋 para a esquerda. Após esse deslocamento em frequência, o sinal, agora complexo, não é mais simétrico com relação ao zero. Por fim o sinal é filtrado em metade de sua banda, resultando no sinal complexo de banda-base 퐼(푡) + 푗푄(푡). O modelo encapsulado da demodulação consta de duas partes distintas: down-mixing (oscilador local) e filtro passa-baixas. Devido a relação trigonométrica da exponencial complexa 푒−푖휔푇푋푡 = cos 휔푇푋푡 − 푗 sen 휔푇푋푡, o down-mixing pode ser modelado como a multiplicação da scanline pela componente cossenoidal e senoidal, resultando, respectivamente, nas componente real e imaginária do sinal complexo (Figura 6.8). Seu encapsulamento foi realizado com a implementação de uma look-up table contendo: • Um ciclo de seno, mapeado em BRAM, com 4096 pontos representados em ponto fixo de 16 bits variando de -1 a 1. • Lógica de indexação de 12 bits, que acessa a posição do ciclo de seno

correspondente à frequência de estimulação, 푓푇푋, e ao tempo, 푡. Já as componentes I e Q, saídas do down-mixing, são representadas por variáveis inteiras de 16 bits com sinal. Outra implementação possível para o oscilador local seria o uso do algoritmo CORDIC (VOLDER, 1959) para gerar as

205 componentes cossenoidal e senoidal da exponencial complexa, porém a um custo computacional muito maior. A etapa do filtro passa-baixas foi implementada por dois filtros em série. O primeira atenua as componentes de frequência superior a 푓푇푋, enquanto o segundo filtro atenua as componentes de frequência fora da banda de passagem do desejada (banda de passagem do transdutor). De maneira geral um filtro de resposta finita ao impulso (FIR, do inglês, Finite Impulse Response) é representado pela relação: 푃−1

푦(푛) = ∑ 푘푖푥(푛 − 푖) 푖=0 Onde 푃 é a ordem do filtro, 푥(푛) é o sinal de entrada, 푦(푛) é o sinal de saída e 푘푖 são os coeficientes do filtro. Há diversas topologias possíveis para a implementação dessa relação. Considerando a estrutura do bloco DSP48E1 (Figura 6.8) e a explorando a simetria dos coeficientes gerado por técnica de janelamento, onde os coeficientes são gerados considerando um filtro com resposta ao impulso infinita (IIR, do inglês, Infinite Impulse Response) ideal e então truncando esta resposta numa função janela de tamanho finito, optou-se pela utilização da topologia de forma simétrica transposta. O mapeamento desta topologia para a tecnologia 푃 alvo (FPGA Virtex-6), utiliza ⁄2 blocos DSP48E1 e 푃 LUTs, tal qual apresentado na figura 6.13.

206

Figura 6.13 - Modelo encapsulado: Topologia e mapeamento dos filtros FIR na tecnologia alvo

Fonte: Autoria própria

207

Para cada filtro encapsulado (dois por componente, I e Q), têm-se: • Entrada e saída representadas por variáveis de 16 bits com sinal. • Coeficientes representados por ponto-fixo de 16 bits variando de -1 a 1, armazenados em BRAMs e específicos para cada transdutor (frequência central). • Ordem 8. Com a demodulação da scanline em suas componentes em-fase e quadratura, os dados dos módulos RXs são transferidos para a Concentradora e concatenados (somados amostra a amostra). Após a concatenação a magnitude do sinal é extraída (detecção de envelope) e o envelope do sinal é decimado e transferido para o módulo DSP. A magnitude do sinal demodulado é dado pela relação instantânea: |퐼(푡) + 푗푄(푡)| = √퐼(푡)2 + 푄(푡)2 A realização da soma dos quadrados não constitui um desafio de encapsulamento e implementação na FPGA, sendo modelado como 퐼 ∙ 퐼 + 푄 ∙ 푄 e mapeado em dois blocos DSP48E1, resultando numa variável de 32 bits sem sinal. Já para o encapsulamento da raiz quadrada inteira de um número inteiro, adotou primeiro um modelo ótimo, no nível das portas lógicas, de um algoritmo não- restaurativo (SUTIKNO, 2011), representado na figura 6.14.

208

Figura 6.14 - Modelo encapsulado: Implementação do algoritmo não-restaurativo de raiz quadrada: a. Implementação para 6 bits; e, b. Estrutura interna e mapeamento do bloco CSM usando os componentes CLB da família Virtex-6

Fonte: Modificado de SUTIKNO (2011)

209

Esta abordagem, embora otimizada quanto ao uso de recursos da FPGA (LUTs), e compatível com a estrutura pipeline da arquitetura do sistema, resultou num código gerado incompatível com as constraints de tempo de execução e roteamento. A alternativa para a modelagem e encapsulamento da operação de raiz quadrada inteira de um número inteiro foi considerar a relação √퐴 = 퐵2. Desta foram, testa-se, recursivamente, para cada bit, se o quadrado do valor sob investigação, 퐵, é menor que o valor de entrada, 퐴, adicionando-se um novo bit em caso positivo e deslocando o bit em um caso contrário. Nesta abordagem, 퐵2 e 퐴 são variáveis de 32 bits sem sinal, enquanto 퐵, é uma variável de 16 bits, resultando no uso de 16 blocos DSP48E1 para a realização dessa operação em um pipeline. Já a comparação entre os valores de 퐵2 e 퐴 foi modelado sob a seguinte aproximação: A soma de um valor com seu inverso (complemento de um) resulta em todos os bits do resultado iguais a um. Destarte, se adicionado um carry-in igual a um, a saída de carry seria um (carry-out) e o valor da soma seria zero. Considerando-se dois valores distintos, 퐴 e 퐵 , determinar se 퐴 ≥ 퐵 é determinar se o carry-out da soma de 퐴 com o complemento de um de 퐵 é igual a um (para 퐴 = 퐵 a soma é zero e para 퐴 < 퐵 o carry-out é zero). Desta forma apenas a lógica de carry, esquematizada na figura 6.15, é necessária para a comparação. No total, 16 LUTs são usadas para cada comparação (variáveis de 32 bits), resultando no custo de 256 LUTs e 18 blocos DSP48E1 para realizar raiz quadrada inteira da soma dos quadros dos componentes 퐼 e 푄 do sinal.

Figura 6.15 - Modelo encapsulado: Lógica de carry

210

Fonte: Autoria própria

O envelope da scanline é então decimado por um fator de oito. Decimar é reduzir a taxa de amostragem de um sinal. A abordagem direta é remover amostras do sinal, assim, o sinal decimado é toda n-ésima amostra do sinal original. Entretanto mudar a frequência de amostragem de um sinal muda sua largura de banda, uma vez que esta é metade da frequência de amostragem (teorema de Nyquist-Shannon). Desta forma, para prevenir o efeito de aliasing, a energia espectral do sinal que excede a largura de banda suportada pela nova taxa de amostragem deve ser eliminada (filtro anti-aliasing). Visto que o fator de decimação é uma potência de dois (23 = 8), optou-se por uma cascata de filtros polifásicos com fator de decimação de 2, cuja topologia e mapeamento para um elemento DSP48E1 encontram-se na figura 6.16 (WHEELER, 2013).

Figura 6.16 - Modelo encapsulado: Decimador

Fonte: WHEELER, 2013

Compressão logarítmica (Mapeamento da magnitude) Com o entendimento da compressão logarítmica enquanto um mapeamento que opera uma mudança de domínio, do domínio do sinal para o domínio da imagem, propôs-se um novo método de compressão (FERNANDES et al., 2014) para o sistema back-end digital. Este novo método divide a compressão em três etapas: 1) compressão, 2) mapeamento e 3) adequação tonal.

211

A etapa de compressão representa em escala logarítmica a magnitude do sinal (envelope) comprimido a certa excursão dinâmica. Na segunda etapa, o envelope comprimido é mapeado por uma função sigmoide que tende a aumentar o contraste nas amplitudes centrais e suavizar nas demais amplitudes. A adequação tonal, último estágio da regra de compressão proposta, trata da distinguibilidade tonal – A relação matemática das etapas é detalhada no artigo Nova Regra de Compressão Logarítmica Aplicada à Imagens Ultrassônicas Modo-B (FERNANDES et al., 2014). O primeiro modelo encapsulado da compressão logarítmica expressava a regra de compressão em sua função matemática utilizando diretivas unroll e must iterate do compilador do C6678 para a geração de código. Entretanto, o código gerado não atendia ao tempo de execução requerido pelo pipeline para o processamento em linha. A alternativa de modelagem para o encapsulamento foi a criação de LUTs que mapeiam a magnitude em seu valor correspondente na compressão logarítmica. Uma vez que a plataforma prevê um ciclo de configuração/operação para cada nova parametrização da aquisição e processamento do sinal ultrassônico, cria-se um nova look-up table para cada nova configuração, tornando a execução da compressão logarítmica um acesso de leitura à memória. Filtro espacial da mediana (Melhoria de atributos do sinal) No filtro espacial da mediana, o pixel central de uma máscara 푀 × 푀 é substituído pela mediana dos pixels nela contidos. Várias tentativas foram feitas para encapsular o filtro espacial da mediana com uma máscara 3 × 3, com diversas técnicas de ordenação: heapsort, bubblesort, quicksort, etc. Entretanto, nenhum código gerado atendia à constraint de tempo de execução para o processamento sobre um frame. Primeiro, pela representação da matriz como um vetor de linhas sequenciadas, que torna a lógica de indexação difícil de ser traduzido da modelo encapsulado para o modelo de implementação (código gerado), gerando um código ineficiente. Depois, pelo custo computacional da ordenação numérica. A opção foi usar a função nativa do C6678 (IMG_median_3x3_8, da biblioteca IMGLIB) que aplica o filtro espacial da mediana sobre uma matriz de

212 pixels – representados por variáveis de 8 bits sem sinal – como modelo de implementação e modelar seu comportamento no modelo encapsulado, mantendo uma relação direta entre os dois modelos. Assim, o modelo encapsulado aplica a técnica de incremental sort (IQBAL et al., 2009), para ordenar os pixels na máscara, e então substitui o valor do pixel central pela mediana dos valores dos pixels na máscara. Transformação de coordenadas e interpolação (Scan conversion) O encapsulamento do scan conversion considerou a tecnologia disponível no início da década de 1980 para a transformação de coordenadas e interpolação e a existência de um ciclo de configuração/operação, que prevê a pausa da operação para cada nova parametrização. Desta forma, o modelo encapsulado aplica transformação cartesiana sobre as coordenadas seguida de interpolação proximal (ou interpolação pelo vizinho mais próximo), formando uma look-up table que mapeia a relação espacial entre os ecos representados nas scan lines e a imagem apresentada no monitor. O método de interpolação proximal usa uma relação determinística no qual estima o valor de um pixel como igual ao pixel mais próximo do conjunto original, sendo determinado a priori, sem a necessidade de ser calculado iterativamente a cada novo frame.

6.1.5 Validação e transferência do conhecimento9

Seria virtualmente impossível validar o isoladamente o processamento back- end digital. Assim, sob o crivo dos membros da RBTU, a plataforma tecnológica desenvolvida no projeto USD foi validada com a implementação do setup de validação proposto no projeto Proto85. Com configuração equivalente entre modelo e encapsulado e plataforma, os cenários de validação foram executados e os resultados comparados entre si. Entretanto, como o back-end é apenas parte do sistema, o setup de validação foi adequado para contemplar as demais características e funcionalidades da plataforma, ampliando os cenários de

9 Esta seção apresenta os resultados obtidos a partir da plataforma tecnológica desenvolvida no projeto USD com a autorização do Instituto de Pesquisas Eldorado (ANEXO A).

213 validação. Posteriormente, com o uso de um voluntário, o sistema foi validado pela ótica de uma profissional especialista em ultrassonografia diagnóstica. Na figura 6.17, a imagem gerada pela plataforma a partir de um phantom comercial CIRS 068 é apresentada e compôs o setup de validação. Já na figura 6.18, apresentam-se imagens adquiridas durante a validação externa com o uso de um voluntário.

Figura 6.17 - Imagem ultrassônica gerada pela plataforma a partir do phantom CIRS 068

Fonte: Autoria própria

214

Figura 6.18 - Imagens ultrassônicas em tempo real obtidas pela plataforma

Fonte: Autoria própria

Os conhecimentos dos problemas específicos foram compilados na estrutura ontológica do catálogo de soluções e nos modelos encapsulados do sistema.

215

Infelizmente, a transferência do conhecimento adquirido durante o desenvolvimento do projeto Proto85 foi resumida à publicação dos artigos relacionados ao processamento back-end, não havendo o exercício ou a prática da plena comunicação e transferência dos conhecimentos técnicos adquiridos. Dos artigos, listam-se: • O artigo Model-Driven Engineering Applied to the Development of Embedded Software for B-Mode Ultrasound Imaging Systems: A Case Study (ONISTO et al., 2014), no qual um workflow baseado em Model-Driven Engineering, arquétipo do processo ARES, é descrito e sua aplicação no desenvolvimento da cadeia de processamento de sinais ultrassônicos é analisada. • O artigo Nova Regra de Compressão Logarítmica Aplicada à Imagens Ultrassônica Modo-B (FERNANDES et al., 2014), que esclarece o entendimento sobre a função da compressão logarítmica e propõe uma nova regra de compressão para imagens modo-B. • O artigo Component-Based Design Guided by an Apparent-Ontology: A Case Study (FERNANDES; ONISTO, 2018), no qual uma abordagem para a criação de uma ontologia aparente baseada em modelos, utilizando a ideia de transformação da informação, é discutida e sua aplicação no desenvolvimento de uma cadeia de processamento de sinais ultrassônicos, seguindo o paradigma component-based development (BARTHOLET et al., 2004), é apresentada.

6.2 O PROCESSO ARES SOB A ANÁLISE DOS REQUISITOS

Como o caso de estudo foi conduzido em um subsistema autocontido em pequena escala, e como os desenvolvimentos do projeto e do processo ocorreram concomitantemente, os resultados do desenvolvimento não abarcaram todas as recomendações e atividades do processo ARES; por exemplo, embora as atividades relacionadas à modelagem do sistema tenham sido satisfatoriamente cobertas, as atividades relacionadas ao suporte às atividades de gerenciamento

216 não foram adequadamente abordados. A seguir, sintetiza-se a análise do processo ARES quanto ao atendimento às características e requisitos desejáveis à inovação (ver Capítulo 3, Seção 3.2). Clareza nas definições e processos: A descrição do processo sob três diferentes perspectivas – atividades, esforço de modelagem e gestão do conhecimento – oferece uma visão detalhada, racional e clara de suas atividades e artefatos, além de fornecer um conjunto compreensível e razoável das propriedades e aspectos dos produtos de cada etapa de desenvolvimento. Aderência às normas e políticas aplicáveis: As decisões tomadas em cada etapa do desenvolvimento são rastreadas a partir dos artefatos que estas modificam. Assim, cada nível de abstração traz consigo o conjunto de decisões específicas que foram adotadas em sua criação, permitindo que análises de regressão e impacto sejam realizadas até ou a partir de uma decisão particular. Cobertura: Ao longo de seu desenvolvimento, o processo ARES se manteve compatível com a estrutura do meta-processo “Vee” desde sua concepção, garantindo a aderência do processo às fases de um ciclo de vida geral de desenvolvimento. Em cada uma de suas perspectivas, o processo prover ainda mecanismos para a construção dos artefatos e gestão do conhecimento, dando suporte às atividades de pesquisa e à pesquisa continuada. Uniformidade: Com a adoção dos conceitos da meta-metodologia MDA e do framework LCIM, o processo ARES apresenta transições bem definidas e ainda assim graduais e suaves entre fases, atividades e artefatos. Rastreabilidade: O refinamento contínuo dos modelos e artefatos no processo ARES confere rastreabilidade plena entre todos os níveis de abstração. Coerência dos artefatos: O contínuo refinamento de um conjunto base de modelos, da cognição à implementação do sistema, confere simplicidade e plausibilidade ao desenvolvimento, enquanto que a adoção dos frameworks LCIM e Rugby confere suficiência aos seus artefatos e modelos. Gerenciamento de ponta-a-ponta: A estrutura hierárquica do processo ARES, pautada no predicado de validação e refinamento contínuos de seus artefatos,

217 permite que o gerenciamento em diferentes níveis e granularidades em toda a extensão do ciclo de vida da pesquisa aplicada. Independência intra e inter desenvolvimento: A incorporação do framework LCIM ao processo ARES garante a maturidade dos artefatos e modelos em cada etapa do desenvolvimento, ao passo que a validação contínua e o caráter evolutivo imposto aos artefatos e modelos permitem a ampla comunicação do desenvolvimento no nível de abstração e granularidade pertinentes. Ferramenta-independente: O processo ARES não faz uso e nem prescreve um conjunto específico de ferramentas ou linguagens para a criação de seus artefatos e modelos. Ao contrário, o processo descreve as características que um conjunto particular de ferramentas deve atender para compor o ambiente de modelagem e simulação. Validação contínua: O processo ARES traz em seu cerne um mecanismo de validação contínua detalhado na descrição de suas atividades e suportado pelos critérios de validade gerencial de modelos (SHELLENBERGER, 1974). Pesquisa: A descrição do processo ARES sob a perspectiva da gestão do conhecimento abrange as atividades particulares de uma pesquisa acadêmica, considerando, por exemplo, o levantamento bibliográfico e a divulgação da pesquisa nos veículos de comunicação científica.

218

7 CONSIDERAÇÕES FINAIS

Assim como esperado num esforço de desenvolvimento de sistemas ou softwares de domínio-específico, os objetivos particulares endereçados no esforço de desenvolvimento do processo ARES foram manifestados num conjunto de requisitos identificados pela análise do domínio do problema (ver Capítulo 3), balizado pelo propósito de pesquisa continuada. Com foco neste propósito, e concentrando o esforço no atendimento aos requisitos, produziu-se um processo, nomeado ARES, utilizando técnicas coerentes e intuitivas, integrando ideias e conceitos de metodologias, processos e frameworks existentes. O método iterativo híbrido usado no design do processo ARES, baseia-se na priorização dos requisitos e características desejáveis à inovação, operando tanto como uma técnica de gerenciamento de complexidade quanto como uma ferramenta de aprimoramento contínuo (ver Capítulo 4). Como resultado, em cada ciclo de design um conjunto particular de requisitos pôde ser trabalhado independentemente, atribuindo às primeiras iterações a estrutura de um projeto de desenvolvimento, e abarcando, nas iterações posteriores, atividades de modelagem e simulação. Em sua versão inicial, o processo ARES não contempla, nem poderia contemplar, a totalidade de seus requisitos, principalmente por não ter sido aplicado extensivamente, limitando-se a um caso teste restringido a um subsistema, nem incorporado à prática de uma instituição de pesquisa. Entretanto, seu arquétipo permite a adição ou modificação de atividades e subprocesso, conferindo-lhe flexibilidade e extensibilidade, permitindo o aprimoramento contínuo do processo. A seguir destacam-se as principais contribuições e resultados alcançados com o desenvolvimento do processo ARES: 1. Um processo de desenvolvimento de sistemas centrada em modelagem e simulação fortemente influenciado pelo processo FDD e pela meta-metodologia MDA. 2. Uma abordagem evolutiva que fornece transições suaves em toda a extensão do desenvolvimento, partindo do domínio do problema até a modelagem do

219

sistema, e do modelo do sistema para o design e implementação, usando critérios de transição bem definidos e abstrações controladas. 2.1. Adoção do modelo de interoperabilidade conceitual (LCIM), estendido pela interoperabilidade intensional, definida nesta dissertação, e a correlação entre seus diferentes níveis e os conceitos MDA. 3. Incorporação ativa da gestão do conhecimento no processo de desenvolvimento, com a criação de uma estrutura ontológica, baseada no trabalho de Couclelis (2010). 3.1. Adoção conjunta dos critérios de validade gerencial de modelos (SCHLLENBERGER, 1974) e das medidas funcionais de Gangemi et al. (2005), na avaliação e validação do conjunto de modelos e artefatos e da ontologia correspondente. 3.2. Vínculo explícito entre a aquisição e aplicação do conhecimento e a cadeia de atividades do processo ARES. 4. Uma estratégia de validação contínua baseada em cenários simuláveis comuns entre os diferentes níveis de abstração. 5. Um processo que dá suporte ao empreendimento da inovação, considerando a relação íntima entre ciência, engenharia e indústria (CALLAOS, 2018), no contexto da pesquisa aplicada de engenharia. 6. Um processo flexível capaz de lidar com diferentes classes de sistemas, e.g. safety-critical, sistemas de informação, etc. É bem verdade que, como todo empreendimento humano ou natural, o processo ARES está sujeito à concepção darwinista de seleção natural, provando- se apto apenas a posteriori. De fato, apenas sob a outorga do tempo, pode-se provar útil ou possuidor de algum valor. Entretanto, o processo ARES possui potencial suficiente para tornar-se parte da prática comum em centros de pesquisas, ICTs e outras instituições de pesquisa e desenvolvimento. Com o processo ainda em sua versão inicial, existem muitos cursos potenciais para aprofundá-lo ou complementá-lo, alguns dos quais listam-se abaixo: • Aplicar o processo em diferentes escopos e sob diferentes classes de sistemas.

220

• Realizar um estudo comparativo entre o processo ARES e outros processos e metodologias. • Definir estratégia de suporte gerencial para incorporação e aplicação do processo ARES, com a criação de um conjunto de boas práticas e guias que permita a coordenação de diferentes centros ou departamentos sob o ciclo de vida do processo. • Estender a análise e aplicação dos frameworks usados no processo, a exemplo dos ciclos descrição-prescrição do framework LCIM ou das dimensões do framework Rugby. • Avaliar a estrutura ontológica do processo e sua capacidade em armazenar o conhecimento adquirido durante o desenvolvimento de sistemas. • Demonstrar a compatibilidade entre o processo ARES e as atividades e métodos particulares das diversas disciplinas da engenharia.

7.1 ARTIGOS PUBLICADOS

Abaixo, listam-se os artigos e trabalhos publicados pelo autor, ou em parceria com o mesmo, no decurso de seu mestrado.

FERNANDES, R. C.; MACHADO, T. M.; MEDEIROS JR, J. D.; ONISTO, H. J.; BERTUZZO, J. E.; COSTA, E. T. Nova Regra de Compressão Logarítmica Aplicada à Imagens Ultrassônica Modo-B. In: XXIV CONGRESSO BRASILEIRO DE ENGENHARIA BIOMÉDICA (CBEB 2014), 24., 2014. Uberlândia, Brasil. Anais… Rio de Janeiro, Brasil: SBEB, 2014. p. 1757-1760.

FERNANDES, R. C.; MACHADO, T. M.; MEDEIROS JR, J. D.; ONISTO, H. J.; BERTUZZO, J. E.; COSTA, E. T. A New Log-compression Rule for B-mode Ultrasound Imaging Adjusted to the Human Visual System. In: XXIV IUPESM WORLD CONGRESS ON MEDICAL PHYSICS & BIOMEDICAL ENGINEERING (WC’15), .24, 2015, Toronto, Canadá.

221

FERNANDES, Ramon Cravo; ONISTO, Haroldo José. Component-Based System Design Guided by an Apparent-Ontology: A Case Study in Ultrasound Imaging. In: THE 9th INTERNATIONAL MULTI-CONFERENCE ON COMPLEXITY, INFORMATICS AND CYBERNETICS (IMCIC 2018), 9., 2018. Orlando, EUA. Anais… Winter Garden, EUA: IIIS, 2018. p. 155-159.

FERNANDES, Ramon C.; ONISTO, Haroldo J.; MEDEIROS JR, Johannes D. Collaborative Design Decision Assisted by Modelling & Simulation: A Cardiac Pacemaker Case Study. In: THE 9th INTERNATIONAL MULTI-CONFERENCE ON COMPLEXITY, INFORMATICS AND CYBERNETICS (IMCIC 2018), 9., 2018. Orlando, EUA. Anais… Winter Garden, EUA: IIIS, 2018. p. 199-203.

MEDEIROS JR, J. D.; CAZARIN FILHO, J. C.; FERNANDES, R. C.; MACHADO, T. M.; BERTUZZO, J. E.; COSTA, E. T.; ONISTO, H. J. Formação de Imagens por Ultrassom em Tempo Real Utilizando um DSP Multicore. In: XXIV CONGRESSO BRASILEIRO DE ENGENHARIA BIOMÉDICA (CBEB 2014), 24., 2014. Uberlândia, Brasil. Anais… Rio de Janeiro, Brasil: SBEB, 2014. p. 1761-1764.

ONISTO, H. J.; MACHADO, T. M.; FERNANDES, R. C.; MEDEIROS JR, J. D.; TAMAGNO, I.; DEZOTTI, T. C.; BERTUZZO, J. E. Model-Driven Engineering Applied to the Development of Embedded Software for B-Mode Ultrasound Imaging Systems: A Case Study in Ultrasound Imaging. In: 2014 IEEE INTERNATIONAL ULTRASONICS SYMPOSIUM (IUS 2014), 54., 2014. Chicago, EUA. Anais… Nova Jersey, EUA: IEEE, 2014. p. 1261-1264.

222

223

REFERÊNCIAS

AKKALA, V.; BHARATH, R.; RAJALAKSHMI, P.; KUMAR, P. Compression Techniques for IoT Enable Handheld Ultrasound Imaging System. In: 2014 IEEE CONFERENCE ON BIOMEDICAL ENGINEERING AND SCIENCES (IECBES), 3., 2014. Kuala Lumpur, Malásia. Anais… Nova Jersey, EUA: IEEE, 2014. p. 648-652.

ALBUQUERQUE, Andréa Corrêa Flôres. Um Framework Conceitual para Integrar Conhecimento Tácito Científico. 178 f. Tese (Doutorado em Informática) – Programa de Pós-Graduação em Informática, Universidade Federal do Amazonas, Manaus, Brasil, 2016.

ALI, M.; STOTZER, E.; IGUAL, F. D.; van de GEIJIN, R. A. Level-3 BLAS on the TI C6678 Multi-core DSP. In: 24th INTERNATIONAL SYMPOSIUM ON COMPUTER ARCHITECTURE AND HIGH PERFORMANCE COMPUTING (SBAC-PAD), 24., 2012. Nova York, EUA. Anais… Nova Jersey, EUA: IEEE, 2012. p. 179-186.

AMDAHL, Gene Myron. Validity of the single processor approach to achieving large scale computing capabilities. In: AMERICAN FEDERATION OF INFORMATION PROCESSING SOCIETIES (AFIPS) SPRING JOINT COMPUTER CONFERENCE, 30., 1967. Atlantic City, EUA. Anais… Washington, EUA: Thomson Book Company, 1967. p. 483-485.

ARISTÓTELES. Nicomachean Ethics: Ηθικά Νικομάχεια. Tradução de Sir William David Ross. Kitchener, Canadá: Batoche Books, 1999.

AUXILIAR, Maria João Patrício do Rosário Morgado. O Modelo TRIPLE HELIX: As Relações entre a Universidade de Coimbra e a Indústria. 51 f. Dissertação

224

(Mestrado em Economia Local) – Faculdade de Economia, Universidade de Coimbra, Coimbra, Portugal, 2010.

BALCI, Osman. Validation, Verification, and Testing Techniques Throughout the Life Cycle of a Simulation Study. In: 1994 WINTER SIMULATION CONFERENCE, 26., 1994. Orlando, EUA. Anais… Nova Jersey, EUA: IEEE, 1994. p. 215-220.

BALMELLI, L.; BROWN, D.; CANTOR, M.; MOTT, M. Model-Driven Systems Development. IBM Systems Journal, Riverton, EUA, v. 45, n. 3, p. 569-585, jul. 2006.

BARCLAY, R. O.; MURRAY, P. C. What is knowledge management?, 1997. Disponível em: . Acesso em: 15 nov. 2015.

BARTHOLET, R. G.; BROGAN, D. C.; REYNOLDS, P. F.; CARNAHAN, J. C. In Search of the Philosopher’s Stone: Simulation Composability versus Component- Based Software Design. In: 2004 FALL SIMULATION INTEROPERABILITY WORKSHOP, 24., 2004. Orlando, EUA. Anais… Bedford, EUA: SISO – Simulation Interoperability Standards Organization, 2004. artigo 04F-SIW-054. Não paginado.

BOEHM, Barry William. Some Future Trends and Implications for Systems and Software Engineering Processes. Systems Engineering, Nova Jersey, EUA, v. 9, n. 1, p. 1-19, 2006.

BRINKKEMPER, Sjaak. Method engineering: engineering of information systems development methods and tools. Information and Software Technology, Amsterdã, Holanda, v. 38, n. 4, p. 275-280, abr. 1996. Disponível em:

225

. Acesso em 12 out. 2015.

BRUEL, J. M.; COMBEMALE, B.; OBER, I.; RAYNAL, H. MDE in Practice for Computational Science. Procedia Computer Science, Amsterdã, Holanda, v. 51, p. 660-669, set. 2015.

CAI, Lukai. Estimation and Exploration Automation of System Level Design. 220 f. Tese (PhD em Informação e Ciência da Computação) – Departamento de Informação e Ciência da Computação, Universidade da Califórnia, Irvine, EUA, 2004.

CALLAOS, Nagib. The Essence of Engineering and Meta-Engineering: A Work in Progress, 2018. Disponível em: . Acesso em: 18 mar. 2018.

CANTOR, Murray. Rational Unified Process® for System Engineering, RUP SE® Version 2.0. IBM Rational Software white paper, Cupertino, EUA: Rational Software, 2003.

CELEST, R. F.; GRISWOLD, A.; STRAF, M. L. Futhering America’s Research Enterprise. Washington D.C., EUA: The National Academies Press, 2014.

CHEN, Duo; MCGOUGH, Robert J. A 2D Fast Near-field Method for Calculating Near-field Pressures Generated by Apodized Rectangular Pistons. Journal of the Acoustical Society of America, Nova York, EUA, v. 124, n. 5, p. 1526-1537, nov. 2008.

226

CHEN, Zhouye. Reconstruction of Enhanced Ultrasound Images from Compressed Measurements. 143 f. Tese (Doutorado em Matemática, Informática e Telecomunicações) – Instituto de Pesquisa em Informática de Toulouse, Universidade Paul Sabatier – Toulouse III, Toulouse, França, 2016.

CHOI, Jongsok. Enabling Hardware/Software Co-design in High-level Synthesis. 177 f. Tese (Mestrado em Ciência Aplicada) – Departamento de Engenharia Elétrica e de Engenharia de Computação, Universidade de Toronto, Toronto, Canadá, 2012.

COAD, Peter et al. Java Modeling in Color with UML: Enterprise Components and Process. Upper Saddle River, EUA: Prentice Hall PTR, 1999.

COMPTON, Paul; JANSEN, Robert. A Philosophical Basis for Knowledge Acquisition. Knowledge Acquisition, Londres, Reino Unido, v. 2, n. 3, p. 241-258, set. 1990.

COUCLELIS, Helen. Ontologies of Geographic Information. International Journal of Geographical Information Science, Londres, Reino Unido, v. 24, n. 12, p. 1785- 1809, dez. 2010.

COYLE, Geoff; EXELBY, David. The Validation of Commercial System Dynamics Models. System Dynamics Review, San Diego, EUA, v. 16, n 1, p. 27-41, abr. 2000.

CROCKER, David. Safe Object-Oriented Software: The Verified Design-By-Contract Paradigm. In: REDMILL, Felix; ANDERSON, Tom (Eds). Practical Elements of Safety: Proceedings of the Twelfth Safety-critical Systems Symposium, Birmingham, UK, 17-19 February 2004. 1. ed. Londres, Reino Unido: Springer- Verlag London, 2004, p. 19-41.

227

CZARNECKI, Krzysztof; HELSEN, Simon. Feature-based Survey of Model Transformation Approaches. IBM Systems Journal, Riverton, EUA, v. 45, n. 3, p. 621-645, fev. 2006.

DAHNOUN, Naim. Multicore DSP: From Algorithms to Real-time Implementation on the TMS320C66x SoC. Chichester, Reino Unido: John Wiley & Son Ltd., 2018.

DEARING, Andrew. Sustainable Innovation: Drivers and Barriers. In: ORGANISATION FOR ECONOMIC CO-OPERATION AND DEVELOPMENT (OECD) WORKSHOP ON INNOCATION AND ENVIRONMENT, 15., 2000. Paris, França. Anais… Paris, França: OECD, 2000. p. 103-122.

DICKIN, David; SHANNON, Lesley. Exploring FPGA Technology Mapping for Fracturable LUT Minimization. In: 2011 INTERNATIONAL CONFERENCE ON FIELD-PROGRAMMABLE TECHNOLOGY (FPT’11), 8., 2011. Nova Deli, China. Anais… Nova Jersey, EUA: IEEE, 2011. p. 1-8.

DUDZIAK, Elisabeth Ariana. Lei de inovação e pesquisa acadêmica: o caso PEA. 374 f. Tese (Doutorado em Engenharia de Produção) – Departamento de Engenharia de Produção, Escola Politécnica da Universidade de São Paulo, São Paulo, Brasil, 2007.

ENCYCLOPÆDIA BRITANNICA. Engineering, 2017. Disponível em: . Acesso em: 25 jan. 2018.

ERDEN, M.; KOMOTO, H.; VAN BEEK, T.; D’AMELIO, V.; ECHAVARRIA, E.; TOMIYAMA, T. A Review of Function Modeling: Approaches and Applications. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, Cambridge, Reino Unido, v. 22, n. 2, p. 147-169, mar. 2008.

228

ESTEFAN, Jeffrey Allen. INCOSE-TD-2007-003-02: Survey of Model-Based Systems Engineering (MBSE) Methodologies. Pasadena, EUA: International Council on Systems Engineering (INCOSE), 2008. Disponível em: . Acesso em: 20 ago. 2015.

ETZKOWITZ, Henry. The Triple Helix of University, Industry and Government: Innovation in Action. Nova York, EUA: Routledge, 2008.

ETZKOWITZ, Henry; LEYDESDORFF, Loet. The Triple Helix of University-Industry- Government Relations: A Laboratory for Knowledge Based Economic Development. European Association for the Study of Science and Technology (EASST) Review, Maastricht, Holanda, v. 14, n. 1, p. 14-19, fev. 1995.

ETZKOWITZ, Henry; LEYDESDORFF, Loet. The Dynamics of Innovation: from National Systems and “Mode 2” to a Triple Helix of University-Industry-Government Relations. Research Policy, Amsterdã, Holanda, v. 29, n. 2, p. 109-123, fev. 2000.

EULER, Leonhard. Solutio Problematis ad Geometriam situs Pertinentis. Commentarii Academiae Scientiarum Imperialis Petropolitanne, São Peterburgo, Rúsia, v. 8, p. 128-140, 1736. Disponível em: . Acesso em: 13 de fev. 2018.

EVANS, Eric. Domain-Driven Design: Tracking Complexity in the Heart of Software. Boston, EUA: Addison-Wesley, 2004.

FARINHA, Luís Manuel do Carmo; FERREIRA, João José de Matos. Triangulation of the Triple Helix: A Conceptual Framework, 2013. Disponível em:

229

. Acesso em: 12 mar. 2017.

FARINHA, Luís Manuel do Carmo; FERREIRA, João José de Matos; GOUVEIA, Joaquim Borges. Networks of Innovation and Competitiveness: A Triple Helix Case Study. Journal of the Knowledge Economy, Nova York, EUA, v. 7, n. 1, p. 259- 275, mar. 2016.

FECHNER, Gustav Theodor. Elements of Psychophysics. Vol. 1. Tradução de Helmut E. Adler. Nova York, EUA: Holt, Rinehart and Winston Inc., 1966.

230

FERREIRA, Fernando Guimarães. A Dialética Hegeliana: Uma Tentativa de Compreesão. Estudos Legislativos, Porto Alegre, Brasil, ano 7, n. 7, p. 167-184, jun. 2013.

FRENKEN, Koen. Technology Innovation and Complexity Theory. Economics of Innovation and New Technology, Abingdon-on-Thames, Reino Unido, v. 15, n. 2, p. 137-155, 2006.

GANGEMI, A.; CATENACCI, C.; CIARAMITA, M.; LEHMANN, J. Ontology Evaluation and Validation: An Integrated Formal Model for the Quality Diagnostic Task. Roma/Trento, Itália: Laboratory for Applied Ontology, Istituto di Scienze e Tecnologie della Cognizione – Consiglio Nazionale delle Ricerche (ISTC-CNT), 2005. 53 p. (parte do projeto ONTODEV do ministério de pesquisas da Itália)

GERO, John Steven; KANNENGIESSER, Udo. The Function-Behaviour-Structure Ontology of Design. In: CHAKRABARTI, Amaresh; BLESSING, Luciënne Theresia Maria (Eds). An Anthology of Theories and Models of Design: Philosophy, Approaches and Empirical Explorations. 1. ed. Londres, Reino Unido: Springer- Verlag London, 2014, p. 263-283.

GIBBONS, M.; LIMOGES, C.; NOWOTNY, H.; SCHWARTZMAN, P. S.; TROW, M. The New Production of Knowledge: The Dynamics of Science and Research in Contemporary Societies. Londres, Reino Unido: Sage, 1994.

GREENBERGER, M.; CRENSEN, M. A.; CRISSY, B. L. Models in the Policy Process. 1. ed. Nova York, EUA: Russel Sage Foundation, 1976.

HALL, Anthony; CHAPMAN, Roderick. Correctness by Construction: Developing a Commercial Secure System. IEEE Software, Los Alamitos, EUA, v. 19, n. 1, p. 18- 25, jan-fev. 2002.

231

HEGEL, Georg Wilhelm Friedrich. Fenomenologia do Espírito. Parte II. 1. ed. Petrópolis, Brasil: Vozes, 1998.

HUCHARD, M.; HACENE, M. R.; ROUME, C.; VALTCHEV, P. Relational Concept Discovery in Structured Datasets. Annals of Mathematics and Artificial Intelligence, Dordrecht, Holanda, v.49, n. 1-4, p. 39-76, abr. 2007.

INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING – INCOSE. Object- Oriented Systems Engineering Method. In: WALDEN, David D. et al. (Eds). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. 4. ed. San Diego, EUA: John Wiley & Sons, Inc., 2015. p. 193-197.

INTERNATIONAL CENTERS FOR TELECOMMUNICATION TECHNOLOGY. The next step beyond MBSP: Pattern-Based Systems Processes (PBSP), 2008. Disponível em: . Acesso em: 20 nov. 2015.

IQBAL, S. Z.; GULL, H.; AHMAD, J. Incremental Sorting Algorithm. In: SECOND INTERNATIONAL CONFERENCE ON COMPUTER AND ELECTRICAL ENGINEERING (ICCEE’09), 2., 2009. Dubai, Emirados Árabes Unidos. Anais… Washington, EUA: IEEE Computer Society, 2009. p. 378-381.

JANTSCH, A.; KUMAR, S.; HEMANI, A. The Rugby Model: A Conceptual Frame for the Study of Modelling, Analysis and Synthesis Concepts of Electronic Systems. In: DESIGN, AUTOMATION AND TEST IN EUROPE CONFERENCE AND EXHIBITION, 1999 (DATE ’99), 2., 1999. Munique, Alemanha. Anais… Nova Jersey, EUA: IEEE, 1999. p. 256-262.

JARUS, N.; SARVESTANI, S. S.; HURSON, A. R. Models, Metamodels, and Model Transformation for Cyber-Physical Systems. In: SEVENTH

232

INTERNATIONAL GREEN AND SUSTAINABLE COMPUTING CONFERENCE (IGSC), 7., 2016. Hangzhou, China. Anais… Nova Jersey, EUA: IEEE, 2016. p. 1-8.

JENSEN, Jørgen Arendt. Field II: A Program for Simulating Ultrasound Systems. Medical & Biological Engineering & Computing, Heidelberg, Alemanha, v. 34, suplemento 1, parte 1, p. 351-353, 1996.

JERRAYA, Ahmed Amine et al. Multilanguage Specification for System Design. In: JERRAYA, Ahmed Amine; MERMET, Jean (Eds). System-Level Synthesis. 1. ed. Dordrecht, Holanda: Springer Sicence+Business Media, 1999, p. 103-136.

KARDOS, Martin; DROZDOVÁ, Matilda. Analytical Method of CIM to PIM Transformation in Model Driven Architecture (MDA). JIOS Journal of Information and Organization Sciences, Pavlinska, Croácia, v. 34, n. 1, p. 89-99, jun. 2010. Disponível em: . Acesso em: 11 ago. 2015.

KLAYMAN, Joshua; HA, Young-won. Hypothesis testing in rule discovery: Strategy, structure, and content. Journal of Experimental Psychology: Learning, Memory, and Cognition, Washington DC, EUA, v. 15, n. 4, p. 596-604, jul. 1989.

KLEIN, Tassilo Johannes. Statistical Image Processing of Medical Ultrasound Radio Frequency Data. 203 f. Tese (Doutorado em Ciências Naturais) – Faculdade de Informática, Universidade Técnica de Munique, Munique, Alemanha, 2012.

KLEPPE, A. G.; WARMER, J.; BAST, W. MDA Explained: The Model Driven Architecture™: Practice and Promise. 1. ed. Boston, EUA: Addison-Wesley Longman Publishing Co., 2003. p. 171.

KEUTZER, K.; MALIK, S.; NEWTON, A. R.; RABAEY, J. M.; VINCENTELLI, A. S. System-Level Design: Orthogonalization of Concerns and Platform-Based Design.

233

IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, Nova York, EUA, v. 19, n. 12, p.1523-1543, dez. 2000.

KÖNIG, Dénes. Mathematikai Mulatságok. Budapeste, Hungria: Lampel Róbert, 1905. v.2.

KÖNIG, Dénes. Theorie der Endlichen und Unendlichen Graphen: Kombinatorische Topologie der Streckenkomplexe. Lípsia, Alemanha: Akademische Verlagsgesellschaft mbh, 1936.

KRIEGESKORTE, Nikolaus. Open Evaluation: A Vision for Entirely Transparent Post-Publication Peer Review and Rating for Science. Frontiers in Computational Neuroscience, Lausana, Suíça, v. 6, artigo 79, out. 2012.

KÜSTER, Jochen Malte; ABD-EL-RAZIK, Mohamed. Validation of Model Transformations: First Experience Using a White Box Approach. In: KÜHNE, Thomas (Eds.). Models in Software Engineering. NINETH INTERNATIONAL CONFERENCE ON MODEL DRIVEN ENGINEERING LANGUAGES AND SYSTEMS (MoDELS 2006), 7., 2006, Gênova, Itália. Workshops. Lecture Notes in Computer Science, v. 4364. Berlim-Heidelberg, Alemanha: Springer-Verlag, 2007, p. 193-204.

LAMPORT, L.; SHOSTAK, R.; PEASE, M. The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems, Nova York, EUA, v. 4, n. 3, p. 382-401, jul. 1982.

LEITE, Fernando César Lima. Gestão do conhecimento científico no contexto acadêmico: proposta de um modelo conceitual. 240 f. Dissertação (Mestrado em Ciência da Informação) – Programa de Pós-Graduação em Ciência da Informação, Universidade de Brasília, Brasília, Brasil, 2006.

234

LEMKE, J.; LATUSZYNSKA, M. Validation of System Dynamics Models: A Case Study. Journal of Entrepreneurship Management and Innovation (JEMI), Nowy Targ, Polônia, v. 9, n. 2, p. 45-59, abr-jun. 2013.

LÚCIO, Levi et al. Model Transformation Intents and their Properties. Software & Systems Modeling, Berlim-Heidelberg, Alemanha, v. 15, n. 3, p. 647-684, jul. 2016.

MAHMOOD, S.; LAI, R.; KIM, Y. S. Survey of component-based software development. IET Software, Stevenage, Reino Unido, v. 1, n. 2, p. 57-66, abr. 2007.

MALPAS, Robert. The Universe of Engineering: A UK Perspective. Londres, Reino Unido: The Royal Academy of Engineering, 2000.

MARTIN, Richard Milton. Intension and Decision: A Philosophical Study. 1. ed. Nova Jersey, EUA: Prentice-Hall Inc., 1963.

MARTIS, Morvin Savio. Validation of Simulation Based Model: A Theoretical Outlook. The Electronic Journal of Business Research Methods, Sonning Common, Reino Unido, v. 4, n. 1, p. 39-46, nov. 2006.

MENS, Tom; VAN GORP, Pieter. A Taxonomy of Model Transformation. Electronic Notes in Theoretical Computer Science, Amsterdã, Holanda, v. 152, p. 125-142, mar. 2006.

MERIN, Matthäus. 1652, 1 gravura, calcogravura, 29,5cm x 36,5cm.

METCALFE, John Stanley. Equilibrium and Evolutionary Foundations of Competition and Technology Policy: New Perspectives on the Division of Labor and the Innovation Process. Revista Brasileira de Inovação, Campinas, Brasil, v. 2, n. 1, p. 111-146, jan-jun. 2003.

235

MODELICA ASSOCIATION, Functional Mock-up Interface, 2012. Disponível em: . Acesso em: 11 nov. 2015.

MUNASSAR, N. M. A.; GOVARDHAN, A. A Comparison Between Five Models of Software Engineering. IJCSI International Journal of Computer Science Issues, Doolar Lane, Maurícia, v. 7, n. 5, p. 94-101, set. 2010. Disponível em: . Acesso em: 03 set. 2015.

NOLAN, Brian et al. Model Driven Systems Development with Rational Products. 1. ed. Armonk, EUA: IBM Redbook, 2008.

NONAKA, Ikujiro; KONNO, Noboru. The Concept of “Ba”: Building a Foundation for Knowledge Creation. California Management Review, Berkley, EUA, v. 40, n. 3, p. 40-54, primavera 1998.

NORMAN, Donald Arthur. The Design of Everyday Things: Revised and Expanded Edition. 1. ed. Nova York, EUA: Basic Books, 2013.

NUSEIBEH, Bashar; EASTERBROOK, Steve. Requirements Engineering: A Roadmap. In: 2000 INTERNATIONAL CONFERENCE ON THE FUTURE OF SOFTWARE ENGINEERING (ICSE’00), 22., 2000. Limerick, Irlanda. Anais… Nova York, EUA: ACM, 2000. p. 35-46.

NYSTEDT, Lars; MAGNUSSON, David. Construction of Experience: The Construction Corollary. In: MANCUSO, James C.; ADAMS-WEBBER, Jack Rhodes (Eds.). The Construing Person. 1. ed. Nova York, EUA: Praeger, 1982. p. 33-44.

236

Imaging Systems: A Case Study in Ultrasound Imaging. In: 2014 IEEE INTERNATIONAL ULTRASONICS SYMPOSIUM (IUS 2014), 54., 2014. Chicago, EUA. Anais… Nova Jersey, EUA: IEEE, 2014. p. 1261-1264.

PAIGE, Richard F.; OSTROFF, Jonathan S. The Single Model Principle. Journal of Object Technology, Zurique, Suiça, v. 1, n. 5, p. 63-81, nov-dez. 2002.

PALMER, S. R.; FELSING, J. M. A Practical Guide to Feature-Driven Development. 1. ed. Englewood Cliffs, EUA: Prentice-Hall, 2002.

PICASSO, Pablo. Bull. 1945, 11 gravuras, litografia, 31cm x 46.8cm. Painéis 1, 3, 4 ,5, 6, 8, 9, 11.

PEFFERS, Ken et al. A Design Science Research Methodology for Information Systems Research. Journal of Management Information Systems, Filadelfia, EUA, v. 24, n. 3, p. 45-77, jan. 2008.

POLANYI, Michael. Personal Knowledge: Towards a Post-Critical Philosophy. 1 ed. Chicago, EUA: The University of Chicago Press, 1962.

PORTER, Michael Eugene. The Competitive Advantage of Nations. 1. ed. Nova York, EUA: Palgrave MacMillan, 1990.

RALYTÉ, J.; ROLLAND, C.; DENECKÉRE, R. Toward a meta-tool for change- centric method-engineering: A typology of generic operators. In: INTERNATIONAL CONFERENCE ON ADVANCED INFORMATION SYSTEMS ENGINEERING, 16., 2004. Riga, Letônia. Anais… Berlim-Heidelberg, Alemanha: Springer-Verlag, 2004. p. 202-218.

237

RAMSIN, Raman. The Engineering of an Object-Oriented Software Development Methodology. 383 f. Tese (PhD em Ciência da Computação) - Departamento de Ciência da Computação, Universidade de York, York, Reino Unido, 2006.

RICCI, N.; SCHAFFNER, M. A.; ROSS, A. M.; RHODES, D. H.; FITZGERALD, M. E. Exploring Stakeholder Value Model via Interactive Visualization. Procedia Computer Science, Amsterdã, Holanda, v. 28, p. 294-303, mar. 2014. Disponível em: . Acesso em 10 jan. 2017.

ROBINSON, Stewart. Conceptual Modelling for Simulation Part I: Definition and Requirements. Journal of the Operational Research Society, Basingstoke, Reino Unido, v. 59, n. 3, p. 278-290, mar. 2008.

ROBKIN, M.; WEININGER, S.; PRECIADO, B.; GOLDMAN, J. Levels of Conceptual Interoperability Model for Healthcare Framework for Safe Medical Device Interoperability. In: 2015 IEEE SYMPOSIUM ON PRODUCT COMPLIANCE ENGINEERING (ISPCE), 10., 2015. Chicago, EUA. Anais… Nova Jersey, EUA: IEEE, 2015. p. 1-8.

ROUSE, W. B.; CANNON-BOWERS, J. A.; SALAS, E. The Role of Mental Model in Team Performance in Complex Systems. IEEE Transactions on Systems, Man, and Cybernetics, Nova Jersey, EUA, v. 22, n. 6, p. 1296-1308, nov. 1992.

ROYAL ACADEMY OF EGINEERING. What is engineering?, 2018. Disponível em: . Acesso em: 25 jan. 2018.

RUMBAUGH, James et al. The Unified Modeling Language Reference Manual. 2. ed. Boston, EUA: Addison-Wesley, 2005.

238

SANDERSON, Penelope M.; MURTAGH, James M. Predicting Fault Diagnosis Performance: Why Are Some Bugs Hard to Find?. IEEE Transactions on Systems, Man, and Cybernetics, Nova Jersey, EUA, v. 20, n. 1, p. 274-283, jan-fev. 1990.

SARGENT, R. G.; GLASOW, P. A.; KLEIJNEN, J. P. C.; LAW, A. M.; MCGREGOR, I.; YOUNGBLOOD, S. Strategic Directions in Verification, Validation, and Accreditation Research. In: 2000 WINTER SIMULATION CONFERENCE, 32., 2000. Orlando, EUA. Anais… Nova Jersey, EUA: IEEE, 2002. p. 909-916.

SCHELLENBERGER, Robert Earl. Criteria for Assessing Model Validity for Managerial Purpose. Decision Sciences, Houston, EUA, v. 5, n. 4, p. 644-653, out. 1974.

SCIENCE AND TECHNOLOGY ORGANIZATION – STO. STO-TR-MSG-086-Part- II: Guideline on Scenario Development for (Distributed) Simulation Environment. Neuilly-sur-Seine, França: North Atlantic Treaty Organization – Science and Technology Organization, 2015.

SENDAL, Shane; KOZACZYNSKI, Wojtek. Model Transformation: The Heart and Soul of Model-Driven Software Devleopment. IEEE Software, Los Alamitos, EUA, v. 20, n. 5, p. 42-45, set-out. 2003.

SHAW, Mildred Louise Gill; WOODWARD, James Brian. Modeling Expert Knowledge. Knowledge Acquisition, Londres, Reino Unido, v. 2, n. 3, p. 179-206, set. 1990.

SHRECKENGOST, Raymond Charles. Dynamic Simulation Models: How Valid are They?. In: ROUSE, Beatrice A. et al. (Eds). Self-Report Methods of Estimating Drug Use: Meeting Current Challenges. 1. ed. Maryland, EUA: National Institute on Drug Abuse, 1985. p.63-70.

239

SIMON, Herbert Alexander. Models of Man: Social and Rational – Mathematical Essays on Rational Human Behavior in a Social Setting. 1. ed. Nova York, EUA: John Wiley & Son Inc., 1957.

SMITS, Ruud; KUHLMANN, Stefan. The Rise of Systemic Instruments in Innovation Policy. International Journal of Foresight and Innovation Policy, Olney, Reino Unido, v. 1, n. 1/2, p. 4-32, 2004.

SYSTEM-LEVEL DESIGN DEVELOPMENT WORKING GROUP. VSI Alliance™ System-Level Interface Behavioral Documentation Standard. Los Gatos, EUA: Virtual Socket Interface Alliance. 2000. Disponível em: . Acesso em: 08 jan. 2016.

STOLLENWERK, Maria Fátima Ludovico. Gestão do Conhecimento: Conceitos e Modelos. In: TARAPANOFF, Kira (Org). Inteligência Organizacional e Competitiva. 1. ed. Brasília, Brasil: Editora Universidade de Brasília, 2001, p. 143- 163.

STOKES, Donald Elkinton. Pasteur’s Quadrant: Basic Science and Technological Innovation. 1. ed. Washington D.C., EUA: Brooking Institution Press, 1997.

STORPER, Michael. The Regional World: Territorial Development in a Global Economy. Nova York, EUA: Guilford Press, 1997.

SUTIKNO, Tole. An Efficient Implementation of the Non Restoring Square Root Algorithm in Gate Level. International Journal of Computer Theory and Engineering, Chengdu, China, v. 3, n. 1, p. 46-51, fev. 2011.

TEXAS. SPRS691: TMS320C6678 Multicore Fixed and Floating-Point Digital Signal Processor. Dalas, EUA: Texas Instrument Inc., 2010.

240

TEXAS. SPRUGH7: TMS320C66x DSP CPU and Instruction Set Reference Guide. Dalas, EUA: Texas Instrument Inc., 2010.

TEXAS. SPRUGW0: TMS320C66x DSP CorePac User Guide. Dalas, EUA: Texas Instrument Inc., 2010.

THALHEIM, Bernhard; TROPMANN-FRICK, Marina. Models and their Capability. In: BEIERLE, C.; BREWKA, G.; THIMM, M. (Eds). Computational Models of Rationality: Essays Dedicated to Gabriele Kern-Isberner on the Occasion of Her 60th Birthday. 1. ed. Londres, Reino Unido: College Publications, 2016, p. 52-74.

THALHEIM, Bernhard. Model, to Model, and Modelling: Towards a Theory of Conceptual Models and Modeling – Towards a Notion of the Model, Collection of Recent Papers, 2016. Disponível em: . Acesso em: 19 nov. 2017.

THALHEIM, Bernhard. Model, to Model, and Modelling: Towards a Theory of Models, especially Conceptual Models and Modelling, Second Collection of Recent Papers (2015-2017), 2017. Disponível em: . Acesso em: 19 nov. 2017.

THE INCOSE MBSE PATTERNS WORKING GROUP. Pattern-Based Systems Engineering (PBSE), Based On S*MBSE Models: In Any MBSE Language or Toolset, 2015. Disponível em: . Acesso em: 20 nov. 2015.

TOLK, A.; DIALLO, S.; TURNITSA, C. Applying the Levels of Conceptual Interoperability Model in Support of Integratability, Interoperability, and Composability for System-of-Systems Engineering. Journal of systemics, cybernetics and informatics, Orlando, EUA, v. 5, n. 5, p. 65-74, fev. 2007.

241

Disponível em: . Acesso em: 12 jun. 2015.

TREEBY, Bradley Ernest; COX, Benjamin Timothy. K-Wave: MATLAB Toolbox for the Simulation and Reconstruction of Photoacoustic Wave-field. Journal of Biomedical Optics, Bellingham, EUA, v. 15, n. 2, artigo 021314, mar-abr. 2010.

TURNITSA, Charles; TOLK, Andreas. Knowledge Representation and the Dimensions of a Multi-Model Relationship. In: 2008 WINTER SIMULATION CONFERENCE, 41., 2008. Miami, EUA. Anais… Nova Jersey, EUA: IEEE, 2008. p. 1148-1156.

VELHO, Silvia. Relações Universidade-Empresa: Desvelando Mitos. Campinas, Brasil: Autores Associados, 1996.

VOLDER, Jack. The CORDIC Computing Technique. In: 1959 THE WESTERN JOINT COMPUTER CONFERENCE (IRE-AIEE-ACM’59), 5., 1959. São Francisco, EUA. Anais… Nova York, EUA: American Institute of Electrical Engineers, 1959. p. 257-261.

WHORF, Benjamin Lee. Lost Generation Theories of Mind, Language, and Religion. Ann Arbor, EUA: Popular Culture Association by University Microfilms International, 1980.

WIIG, Karl Martin. Knowledge Management Foundations: Thinking About-How People and Organizations Create, Represent, and Use Knowledge. Arlington, EUA: Schema Press, 1993.

WILLIAMSON, Timothy. Vagueness. Londres, Reino Unido: Routledge, 1994. The Problems of Philosophy.

242

WHEELER, David. How to Design IIR Filters for Interpolation and Decimation. Xcell Journal, São José, EUA, v. 85, p. 36-41, out-dez. 2013.

XIAO, Y.; BOILY, M.; HASHEMI, H. S.; RIVAS, H. High-Dynamic-Range Ultrasound: Application for Imaging Tendon Pathology. Ultrasound in Medicine and Biology, Nova York, EUA, v. 44, n. 7, p. 1525-1532, jul. 2018.

XILINX. UG369: Virtex-6 FPGA DSP48E1 Slice User Guide. São José, EUA: Xinlinx Inc., 2011.

XILINX. UG364: Virtex-6 FPGA Configurable Logic Block User Guide. São José, EUA: Xinlinx Inc., 2012.

ZINS, Chaim. Conceptual Approaches for Defining Data, Information, and Knowledge. Journal of the American Society of Information Science and Technology, Hoboken, EUA, v. 58, n. 4, p. 479-493, jan. 2007.

243

ANEXO A