Terminology as the Basis for Building Engineering Feature-based Models

186 Ricardo Eito Brun Terminologia como base para a construção Engineering Feature-based Models doi.org/10.35321/term27-08 (em inglês) A terminologia como base para a construção Engineering Feature-based Models RicaRdo Eito BRun Universidade Carlos III de Madrid Resumo das conclusões As operações de satélites exigem a utilização combinada de diferentes ferramentas para apoiar as actividades de engenharia e para controlar a nave espacial. Esta comunicação é gerenciada pelo Sistema de Monitoramento e Controle (MCS) que recebe dados de telemetria da nave espacial e libera comandos remotos para manter a atitude e a trajetória de voo do satélite. Estes sistemas complexos são desenvolvidos como plataformas abertas que podem ser estendidas e personalizadas para suportar requisitos e objetivos específicos da missão. Como regra geral, pode-se afirmar que estas aplicações de software são bons candidatos para a implementação de mecanismos de variabilidade de forma estruturada e planeada e que a sua funcionalidade é um bom candidato para analisar a viabilidade da aplicação de técnicas de modelagem baseadas em características. Este artigo descreve o uso da análise de terminologia para construir um modelo de características para apoiar a análise de requisitos para este tipo de sistemas baseados em software. Palavras-chave: Terminologia técnica, Modelos baseados em características, Engenharia aeroespacial, Extracção de terminologia ANOTACIJA (em inglês) Palydovų operacijoms reikalingi įvairūs įrankiai, skirti užtikrinti sklandų inžinerinį darbą ir valdyti erdvėlaivį. Palydovų operacijoms reikalingi įvairūs įrankiai, skirti užtikrinti sklandų inžinerinį darbą ir valdyti erdvėlaivį. Šį ryšį valdo Stebėjimo ir kontrolės sistema (SKS), kuri gauna telemetrinius duomenis iš erdvėlaivio ir duoda telekomandas, kadytų palaik palydovo padėtį ir skriejimo trajektoriją. Os sistemas de composição são mais sucurtos do que as plataformas de atviros, as quais podem ser alargadas e adaptadas de acordo com os requisitos de missões concretas e os objetivos. Galime teigti, kad paprastai šios taikomosios programos gali būti naudojamos norint struktūruotai ir planuotai įdiegti variantiškumo mechanizmus, o jų funkcionalumas leidžia analizuoti požymių modeliaus metodikų pritaikymo galimybes. Este artigo descreve as análises terminológicas de utilização dos modelos požymių, os palaikančiam exigem a análise deste tipo de sistemas programáticos, para criar. ESMINIAI ŽODŽIAI: técnica terminologia, požymių modeliai, aviacijos inžinerija, terminų atpažinimas 187Terminologia | 2020 | 27 1. INTROduCTION O glossário da NASA define satélites como: "um objeto de voo livre que orbita a Terra, outro planeta ou o sol". Os satélites são um tipo de nave espacial que viaja em uma órbita regular e claramente definida em torno do centro de gravidade de outro corpo celeste (Garner 1996: 4). Desde o lançamento dos primeiros satélites artificiais - Sputnik 1 em 4 de outubro de 1957 e Explorer 1 em 31 de janeiro de 1958 - um grande número de missões de satélite foram lançadas com diferentes propósitos: exploração astronômica, prestação de serviços de comunicação e navegação, observação da Terra, reconhecimento e missões científicas. Os satélites são sistemas aeroespaciais complexos compostos por elementos terrestres e espaciais: a nave espacial deve ser operada por um elemento de controlo na Terra e permanecer em contacto com ele. Hoje, o progresso científico e os serviços para os utilizadores dependem dos satélites e das constelações de satélites. Exemplos relevantes incluem o Telescópio Espacial Hubble (HST), sistemas de navegação como o GPS (Sistema de Posicionamento Global), o GLONASS e o Galileo Europeu, o UARS (Satelite de Pesquisa da Atmosfera Superior) ou o GOES (Satelite de Ambiente Operacional Geostacionário). O número total de satélites lançados desde 1957 - de acordo com o catálogo SSN2 dos Estados Unidos - é próximo de 18.200; o Índice de Objetos Lançados para o Espaço Exterior de 2017 da uNOOSA relata 4.635 satélites atualmente em órbita do planeta, com um aumento de 357 satélites (8,95%) em relação ao ano anterior. O objectivo deste artigo é demonstrar a necessidade de aplicar a gestão e a extracção de terminologia para apoiar o desenvolvimento de modelos baseados em características para organizar os conceitos que descrevem as funções das aplicações de software utilizadas para o controlo e monitorização por satélite. Os satélites são classificados por finalidade e tipo de órbita. A finalidade refere-se aos serviços que o satélite pretende fornecer. No que diz respeito à órbita, faz-se uma distinção entre órbita terrestre baixa (LEO), órbita terrestre média (MEO) e órbita geoestacionária (GEO). Os satélites LEO […] utilizados para a ciência e a observação da Terra […] seguem uma órbita elíptica; uma vez que a sua visibilidade a partir de estações terrestres é limitada, os dados são armazenados a bordo e enviados para o solo 1 Ver https: www.grc.nasa.gov/www.k-12/TRC-0laefs/laefs_s.html#satellite [accesso 2020-081]. 2 A Rede de Vigilância Espacial dos Estados Unidos é responsável pela detecção, rastreamento, catalogação e identificação de objetos artificiais em órbita terrestre. O catálogo está disponível em: https: www.space-track.org/#/ssr [acesso 2020-08-01]. 3 Escritório das Nações Unidas para Assuntos do Espaço Ultraterrestre. Veja 188 Ricardo Eito Brun Terminologia como base para a construção Engineering Feature-based Models https://www.pixalytics.com/sats-orbiting-earth-2017 estações quando a aeronave se torna visível. Os satélites GEO são utilizados para fins de telecomunicações e meteorológicos; Os satélites de telecomunicações recebem sinais de radiofrequência (RF) da Terra, amplificam-nos, mudam a sua frequência e transmitem-nos de volta para a Terra. Eles orbitam 36000 km acima do Equador (no mesmo plano) e sua rotação é sincrônica com a rotação da Terra, permanecendo acima do mesmo ponto no Equador o tempo todo. Semelhante aos satélites, as missões científicas no espaço profundo também precisam de monitoramento e controle semelhantes para o telecomandos e a recepção de telemetria. As missões de satélites exigem pessoal dedicado para realizar o monitoramento contínuo em tempo real do estado e da posição do satélite. O controle de missão é o conjunto de tarefas executadas após o lançamento por engenheiros de operação com a ajuda de aplicativos de software e envolve a troca de dados entre os segmentos terrestre e espacial para monitorar e controlar o estado dos subsistemas a bordo do satélite. Em missões científicas, também é necessário receber as informações da carga útil do satélite e ecutadas durante o controle da missão incluem a recepção e análise de telemetria, telecomandamento e rastreamento. A telemetria são os dados transmitidos do satélite para a Terra, deliver it to the end-users (scientific community). Typical functions exinformando sobre o estado e as condições do satélite e dos seus subsistemas. Os telecomandos são as ordens transmitidas do solo para a nave espacial para configurá-la e operá-la. (uhlig, Sellmaier e Schmidhuber 2015: 232). O rastreamento e manutenção da estação, também conhecido como ranging, consiste no monitoramento e determinação da trajetória de voo e da posição usando técnicas e sinais de RF. Do ponto de vista da engenharia de software, o controle por satélite requer diferentes aplicações e ferramentas para dinâmica de voo, planejamento de missão, telemetria e telecomando, controle de rede e roteamento, bem como interfaces entre eles. Esta complexidade levou às agências espaciais a fornecerem soluções diferentes. Um dos marcos mais relevantes no desenvolvimento do software MCS foi a decisão do departamento de Engenharia de Sistemas Terrestres da ESA de desenvolver e licenciar para a indústria europeia um conjunto de aplicações de software distribuídas sob o nome MICONYS® 4 satélites GEO são distribuídos em uma área limitada no espaço. Os slots orbitais são atribuídos pela União Internacional de Telecomunicações (ITu) para evitar colisões, um risco relacionado ao tema dos detritos espaciais que está recebendo maior atenção hoje. 189Terminologia | 2020 | 27 (Sistema de Controle de Missão). O MICONYS e o seu componente SCOS-2000 são provavelmente os exemplos mais conhecidos desta política da ESA para o desenvolvimento de software e inovação e transferência de tecnologia (Kaufeler, Jones e Karl 2001). O SCOS-2000 suporta telecomando, recepção de telemetria, exibição e arquivamento. O SCOS-2000 foi o resultado da experiência adquirida pela ESA no desenvolvimento e operação de sistemas semelhantes anteriores: MSSS, SCOS-1 e SCOS-2. Hoje, a ESA está a desenvolver o novo sistema MCS, destinado a substituir o SCOS-2000 no futuro. O seu nome é European Ground Systems […] Common Core (EGS-CC). Semelhante ao SCOS, o projeto tem o objetivo de desenvolver uma infraestrutura comum para apoiar o monitoramento e o controle de missões espaciais nas fases pré e pós-lançamento, usando tecnologias modernas e arquiteturas orientadas a serviços (Pecchioli et al. 2012). O desenvolvimento do EGS-CC não é apenas da responsabilidade da ESA: as agências espaciais nacionais europeias (CNES, Agência Espacial do Reino Unido e DLR) e as empresas industriais (AIRBUS Defence and Space, Thales Alenia Space e OHB Systems) fazem parte do projecto. Além dos projectos da ESA, existem outras iniciativas destinadas a desenvolver um sistema genérico de software MCS. A NASA concluiu projetos semelhantes, a maioria deles desenvolvidos internamente. O Centro de Voo Espacial Goddard desenvolveu dois sistemas, o ITOS e o ASIST, para gerenciar missões como WMAP (Wilkinson Microware Anisotropy Probe), IMAGE (Imager for Magnetopauseto-Aurora Global Exploration), EO-1 (Earth Observing ST-5 (Space Technology 5), SDO (Solar Dynamics Observatory) ou LRO (Lunar Reconnaissance Orbiter) (Pfarr et al. 2007). Em todos estes casos, estamos a lidar com um sistema complexo que precisa de implementar diferentes funções que podem ser activadas ou não, dependendo do satélite e das características da missão. Devido a isso, esses sistemas intensivos em software são bons candidatos a serem desenvolvidos usando linhas de produtos e técnicas de modelagem baseadas em recursos, que dependem de uma organização clara e bem organizada de conceitos para entender o domínio e as capacidades necessárias do sistema. A modelagem baseada em recursos é uma das técnicas aplicadas na engenharia de linhas de produtos de software, uma disciplina para a construção de programas de software reutilizáveis que se tornou popular no final dos anos noventa. A SPLE pretende construir componentes e artefatos reutilizáveis que possam ser posteriormente combinados para construir produtos Ricardo Eito Brun Terminologia como base para a construção Engineering Feature-based Models adequados às necessidades de um cliente e contexto específicos. As experiências em SPLE estão amplamente documentadas na literatura profissional e acadêmica. Capilla (2013) incluiu vários estudos de caso em que o SPLE foi aplicado com sucesso: programas de voo operacionais e de missão crítica da Boeing para a aviônica e as funções do cockpit, software de controle de motor da Bosch para sistemas de gasolina, software de impressora da Hewlett Packard, equipamentos de geração e transmissão de energia da Toshiba e software de controle da General Motors para motores. Os benefícios das linhas de produtos de software (SPL), de acordo com Apel et al. (2013: 9), incluem a adaptação de produtos de software às necessidades específicas dos clientes, redução de custos - uma vez que um conjunto de ativos reutilizáveis pode ser combinado de diferentes maneiras para gerar novos produtos - , melhoria da qualidade e do tempo de lançamento no mercado. As características e a modelagem baseada em características são conceitos relevantes no desenvolvimento do SPL. ISOIEC/IEEE 24765: 2010, Engenharia de Sistemas e Software […] Vocabulário, oferece uma definição geral de recursos, tomada do IEEE Std 829: 2008 IEEE Standard for Software and System Test Documentation: […] Uma característica distintiva de um item de sistema. NOTA: inclui atributos funcionais e não funcionais, tais como desempenho e reutilizabilidade. Kang e Lee (2013, 28) definem as características como "conceitos abstratos que apoiam efetivamente a comunicação entre as diversas partes interessadas de uma linha de produtos e, portanto, é natural e intuitivo que as pessoas expressem a comunidade e a variabilidade das linhas de produtos em termos de características". As características servem diferentes propósitos no processo de ideia e desenvolvimento do produto. São meios de comunicação das características do produto e de apoio à identificação dos requisitos; são também os conceitos que guiam as decisões de concepção e implementação. O desenvolvimento de uma linha de produtos compreende dois ciclos de vida complementares: • engenharia de domínio e • Engenharia de aplicações. O padrão IEEE 1517-2010 define a engenharia de domínio como: […]Ciclo de vida que consiste em um conjunto de processos para especificar e gerenciar a comunidade e a variabilidade de uma linha de produtos. A engenharia de domínio analisa o domínio de uma linha de produtos e desenvolve um conjunto de artefatos reutilizáveis. Estes artefatos incluem requisitos de software, elementos de design, casos de teste e 191Terminologia | 2020 | 27 tipo de engenharia de requisitos para toda a linha procedures, user documentation, etc. domain analysis can be seen as a de produtos, incluindo a identificação da variabilidade antecipada. O artefato principal gerou produtos dentro da linha. by domain analysis is the feature model that will specify and describe the A modelagem de recursos é uma técnica de diagramação que foi introduzida nos anos noventa com a metodologia FOdA (Análise de Domínio Orientada a Recursos). O FOdA forneceu primitivas para representar relações estruturais (composição, generalização e especialização), opcionalidade, alternatividade e dependências mútuas. Mais tarde, foi revisado por diferentes autores (Kang e Lee 2013: 30 […] 31). Os diagramas de recursos são a representação visual de modelos de recursos, onde os recursos são representados como caixas em uma árvore hierárquica. Cada nó tem um rótulo anexado com o nome do recurso. O arranjo hierárquico das características cria relações pai-filho. Se um recurso filho for selecionado, seu pai também deve ser selecionado. Os diagramas podem fazer uma distinção entre características obrigatórias e opcionais e identificar as combinações de características que são válidas. Em particular, os diagramas de características podem representar: • Características abstratas, que são usadas para organizar as características na árvore, mas não estão vinculadas a artefatos de implementação. Eles são representados por caixas cinzentas. • Características concretas, que correspondem a artefatos de implementação e são representadas por caixas brancas. • Características obrigatórias, que têm uma bala preenchida na parte superior da borda superior da sua caixa. • Características opcionais, que têm uma bala não preenchida na parte superior da borda superior da caixa. • A necessidade de selecionar apenas uma das características do filho de um progenitor específico (exclusivo OR, XOR ou um de muitos). É representado com um arco vazio na borda inferior da caixa do recurso pai. • A possibilidade de selecionar mais de uma característica infantil de um progenitor específico (OR ou algumas das muitas). É representado com um arco preenchido na borda inferior da caixa do recurso pai. • dependências entre características, representadas por setas com anotações textuais. 192 Ricardo Eito Brun Terminologia como base para a construção Engineering Feature-based Models O diagrama abaixo mostra um diagrama de características típico com as convenções descritas acima: Figura 1. Exemplo de diagrama de características (Fonte: Gargantini 2015) Um modelo de características deve incluir informações adicionais ao diagrama. Apel et al. (2013: 27) indicam a possibilidade de adicionar estes dados: • Descrição de uma característica e do seu conjunto correspondente de requisitos. • Relação com outras características, especialmente hierarquia, ordem e agrupamento. • Dependências externas, tais como os recursos de hardware necessários. • Partes interessadas. • Custo estimado ou medido de realização de uma característica. • Etc. O desenvolvimento de um modelo de características para representar as características funcionais das aplicações de software para o controlo por satélite deve partir de uma compreensão clara e da modelização dos conceitos que compõem o domínio. Para o efeito, as actividades relacionadas com a terminologia e a terminografia, a identificação de termos, conceitos e as suas relações constituem a base para a construção do modelo-alvo. 193Terminologia | 2020 | 27 3. Metodologia de trabalho O modelo de características proposto foi concluído seguindo as seguintes etapas: • Identificação e revisão da literatura profissional e académica publicada nesta área. Isto envolve a procura de informações sobre a abordagem seguida em projectos aeroespaciais liderados por entidades como a ESA (Agência Espacial Europeia) ou a NASA (Administração Nacional de Aeronáutica e Espaço). • desenvolvimento de um glossário com base na literatura analisada, aplicando técnicas de gestão terminológica para registar informações sobre termos, relações entre eles, definições identificadas nos documentos e o contexto em que os termos são utilizados. • Criação de um modelo baseado em características que represente as funções oferecidas pelas aplicações de software de monitorização e controlo por satélite, utilizando o glossário como base. Os insumos utilizados para identificar os termos incluíram um subconjunto de documentos técnicos que descrevem o produto selecionado: manuais de operação, livros brancos e materiais de formação. O modelo de recursos é uma árvore hierárquica de recursos marcados como obrigatórios ou opcionais, com the case of the software application under analysis, besides the identificadependências entre eles. No que diz respeito às características opcionais e obrigatórias, foram identificados requisitos adicionais de variabilidade da linha de produtos. Em particular, algumas das funções suportadas pelo software em análise requerem a sobrescrição ou a personalização do código existente. A identificação desses casos de variabilidade foi feita com o apoio de especialistas que desenvolvem sua atividade no desenvolvimento e personalização deste tipo de aplicação de software. Foram feitas entrevistas pessoais para recolher essas informações. A ferramenta selecionada para criar o modelo de características e os diagramas é o FeatureIDE5. Esta é uma ferramenta de código aberto baseada em Java e Eclipse, desenvolvida pela equipe da Otto-von-Guericke-Universität Magdeburg. Com o FeatureIDE, é possível criar um modelo de recurso usando um editor gráfico, marcar recursos como obrigatórios, opcionais ou abstratos e construir a árvore hierárquica. Uma vez construído o modelo de recursos, você pode criar diferentes configurações: seleções de recursos que serão usados para gerar o aplicativo de software de destino. Última verificação: 01-03-2018. Ricardo Eito Brun Terminologia como base para a construção 194 Engineering Feature-based Models código-fonte. Infelizmente, a ferramenta não fornece capacidades para gerenciar termos ou unidades terminológicas, o que torna necessário o uso de ferramentas complementares. Figura 2. FeatureIDE (criado pelo autor) 4.Presentação dos resultados e discussões Esta secção resume uma secção do modelo de características para aplicações de software de Sistemas de Controle de Missão (MCS). A análise dos conceitos extraídos dos documentos levou a uma organização das funcionalidades do sistema nas seguintes áreas: • Desktop e Session Management, que fornece as funções para fazer login, iniciar uma sessão e iniciar os diferentes aplicativos. No caso de gestão de vários satélites, o utilizador será capaz de alternar entre os espaços de trabalho dos satélites. • Cadeia de telemetria, que inclui processamento de telemetria, gerenciador de alarme e exibição de telemetria.