Na parte 1 desta série, obtivemos o design do sistema de um controlador terrestre de UAV usando a engenharia de sistemas do IBM Rational Harmony como um processo nos orientando a mostrar os subsistemas e as interfaces lógicas. No entanto, o design dos sistemas distribuídos é frequentemente centrado em dados, onde as entidades de dados assumem o lugar de cidadãos de primeira classe no design de um sistema. Dessa forma, parece apenas óbvio aprimorar um pouco o processo de engenharia de sistemas do Rational Harmony a fim de permitir que o processo de design se concentre nas entidades de dados e ainda assim leve a qualidade de um processo MBSE maduro como a engenharia de sistemas do Rational Harmony para o design.

No design de sistemas distribuídos, é necessário definir essas interações de dados por meio de uma linguagem de interface evoluída que não apenas garante a consistência dos diversos subsistemas durante toda a interação, mas que também possa capturar a intenção e comportamento de interação do conjunto de dados na própria linguagem. Uma etapa como essa na linguagem de especificação de interface em evolução é a especificação de Data Distribution Service (DDS) do OMG (consulte Recursos). Embora o hand-off no final de um processo padrão de engenharia de sistemas do Rational Harmony (consulte Recursos) seja suficiente para mostrar o ICD operacional entre subsistemas das interfaces lógicas obtidas, o mapeamento dessas interfaces lógicas para os desenvolvimentos de troca de informações com Data Distribution Service (DDS) talvez não seja direto.

Neste artigo, tentamos aprimorar o fluxo de trabalho padrão do processo de engenharia de sistemas do Rational Harmony de modo que ele suporte a dissonância distribuída em vez do Rational Harmony. Primeiro, você verá desenvolvimentos da especificação DDS e a Análise de Problem-frame (consulte Recursos). Em seguida, executamos as etapas envolvidas no processo MBSE modificado que engloba o DDS completo durante todo processo de análise e design dos sistemas distribuídos. Finalmente, você poderá executar as etapas usando o mesmo caso de referência usado na parte 1 do artigo.

Entenda o DDS e a análise de problem-frame

A especificação de Data Distribution Service (DDS) do OMG é separada em camadas de arquitetura. A camada inferior é Data Centric Publish and Subscribe (DCPS), que contém interfaces de digitação segura para um mecanismo de comunicação de publicação e subscrição. A camada superior é Data Local Reconstruction Layer (DLRL), que permite aos desenvolvedores de aplicativo criar um modelo de objeto local sobre a camada DCPS, a fim de proteger o aplicativo contra o conhecimento de DCPS. O contexto deste artigo é limitado a alguns desenvolvimentos específicos de DCPS.

Publicação e subscrição centrada nos dados

A camada DCPS dissemina dados de publicadores para assinantes interessados. Ela é implementada usando os conceitos de publicador e produtor de dados no lado remetente e assinante e leitor de dados no lado receptor. A camada DCPS é composta por um ou mais domínios de dados, cada um deles contendo publicadores e assinantes que se comunicam via DDS. Cada publicador e assinante pertence a um domínio. Em qualquer domínio de dados, os dados são identificados por um tópico, que é um segmento de domínio específico ao tipo e permite aos publicadores e assinantes consultar os dados sem ambiguidade.

Dentro de um domínio, um tópico associa um nome de tópico, tipo de dados exclusivo e um conjunto de políticas de qualidade de serviço (QoS) com os próprios dados. Cada tópico é associado a um tipo de dados, embora diversos tópicos diferentes possam publicar o mesmo tipo de dados. O comportamento de publicadores é determinado pelas políticas de QoS associadas ao publicador, produtor de dados e elementos do tópico para uma origem de dados específica. Igualmente, o comportamento dos assinantes é determinado pelas políticas de QoS associadas ao assinante, leitor de dados e elementos de tópico para um coletor de dados. Algumas das políticas e operações de QoS especificadas na linguagem e usadas no caso de referência são exibidas na Tabela 1 e 2 respectivamente. As políticas e operações de QoS.

Análise de Problem-frame

A abordagem de Problem Frames é uma abordagem de análise de requisitos. Ela permite que você categorize os requisitos do sistema como um conjunto de problemas pré-definidos análogo aos padrões de design no espaço da solução. Após a categorização, os problemas podem ser facilmente explicados respondendo um conjunto de perguntas padrão associado a cada quadro de problemas. A Figura 1 mostra como a técnica foi usada neste artigo para documentar os artefatos do caso de referência.

Visualização maior da Figura 1.

Fluxo de trabalho proposto

O fluxo de trabalho proposto para o processo é exibido na Figura 2.

Após definir os casos de referência no nível do sistema na fase de análise dos requisitos, o processo tem como objetivo definir as entidades de dados, atributos e operações para cada um dos casos de uso do sistema por meio da análise de quadro de problemas. É possível usar o quadro de problemas de informação para desenvolver as entidades do modelo e seus atributos, os quadros de problema de conexão e transformação para definição do comportamento dessas entidades e o quadro de problema de material para desenvolver as operações nas entidades definidas.

Em seguida, precisamos definir o modelo de informações do sistema com base nas entidades identificadas na fase de análise de quadro de problemas. O artefato produzido por essa análise é o modelo de tópico que define o nome, o tipo e a qualidade de serviço de tópicos DDS identificados. Como temos o modelo de tópico, na próxima fase da análise funcional de entidade você se concentrará na realização de análises funcionais que envolvem as operações de ciclo de vida das entidades de modelo de tópico identificadas. É possível usar o diagrama de atividades de caixa preta para capturar os fluxos paralelos de ciclo de vida de cada uma das entidades identificadas. Além disso, você precisa gerar os cenários de caso de uso de caixa preta combinando um ou mais fluxos a fim de estabelecer os fluxos funcionais reais como diagramas de sequência. Use a sequência para gerar as portas e interfaces do bloco de caso de referência. Em seguida, capture o comportamento com base no estado do caso de referência e verifique os diagramas de sequência gerados, comparando-os aos diagramas de sequência de cenário de caixa preta.

A síntese do design começa realizando a decomposição estrutural do sistema, não apenas com base nas principais funções, mas também nas próprias entidades de modelo. Na próxima etapa, enquanto descreve o diagrama de atividades de caixa branca, você precisa incluir DDS-Data-space como um dos componentes do subsistema a fim de corrigir os fluxos funcionais independentes. A definição do DDS-Data-space como um componente do subsistema permite que a máquina de estado de caixa branca execute como um modelo executável, preservando a separação no tempo e espaço desejado por meio do uso de DDS. Agora, é possível verificar esse modelo executável comparando os diagramas de sequência que geramos com base naqueles produzidos com cenários de caixa branca. Por fim, você precisa gerar o Internal block diagram (IBD) do sistema que mostra as portas e interfaces de caixa branca. Como era previsível, as interfaces nesse caso mapeiam individualmente para os tópicos no modelo de informações que já definiu adequadamente os atributos e seus comportamentos.

Análise de Problem-frame

O escopo dessa análise, definido pelo caso de referência Perform Area Search, é a detecção de UAVs em voo, atribuindo áreas de pesquisa aos UAVs, adquirindo dados de controle dos sensores e armazenando isso em um modelo de informações. A análise realizada é exibida nas Tabelas 3 e 4.

Análise do modelo de informações

Nessa etapa, você precisa realizar a análise do modelo de informações usando a análise do quadro de problemas de informações e de conexão da fase anterior. O objetivo desta fase é identificar os tópicos DDS que representam as entidades de dados e seu comportamento. Cada tópico forma a unidade de interação em um ambiente DDS. A representação correta de seu comportamento pode reduzir bastante a responsabilidade dos subsistemas com relação à limpeza e ao gerenciamento genérico. Um subconjunto de modelo de informações representativo do caso de referência é exibido na Figura 2.

É possível ver um exemplo dessa redução no comportamento definido para o tópico "SensorTrackMeasure". A descrição da chave (a lista de campos de dados cujo valor forma a chave) definida neste tópico é uma estrutura composta formada pelo SensorID e trackID. Valores de dados diferentes com o mesmo valor de chave representam valores sucessivos para a mesma instância, enquanto valores de dados diferentes com valores de chave diferentes representam instâncias diferentes. Além disso, o HistoryQosPolicy do tópico é definido como KEEP_ALL com uma profundidade de 1800 para indicar que no máximo 1800 amostras de cada instância é mantida no espaço de dados (a atualização de 1 Hz por 30 minutos). Finalmente, o LifespanQosPolicy com uma duração correspondente a 30 minutos, especifica a duração máxima da validade da amostra de dados no espaço DDS, sendo automaticamente descartada depois disso. A definição desse comportamento sobre a entidade SensorTrackMeasure define sem equívoco o serviço DDS para assumir a responsabilidade do gerenciamento do histórico para a entidade. Agora, seria redundante modelar essa funcionalidade no caso de referência.

O modelo de tópico representativo na figura 2 descreve o nome, o tipo e as políticas de qualidade de serviço relacionadas ao tópico "SensorTrackMeasure". Usamos um exercício parecido para o restante do caso de referência para descrever os seguintes tópicos:

• UAVInfo
• SensorTrack
• SensorTrackMeasure
• Command

É importante observar que nem todas as entidades de modelo identificadas durante a fase de análise de quadro de problemas têm correspondência individual ao modelo do tópico.

Análise funcional de entidade

Os dados na fase de análise funcional de entidade são o modelo de tópico e o modelo de análise de quadro de problema de material. Essa fase se concentra na realização da análise funcional das operações de ciclo de vida dos tópicos identificados. Os artefatos produzidos nesta etapa são o diagrama de atividades de caixa preta, os cenários e os gráficos de estado do caso de referência. O diagrama de atividade de caixa preta para o caso de referência é exibido na figura 4, enquanto os cenários representativos e os gráficos de estado são exibidos nas figuras 5 e 6 respectivamente.

O diagrama de atividade de caixa preta representa as ações baseadas em desenvolvimentos DDS como read, write, content_filter ou read_with_query_condition. Esses desenvolvimentos são meios de simplificar os fluxos funcionais. Levar essa ligação ao fluxo de atividades é considerado essencial para conseguir a eficiência funcional por meio do uso de DDS. Por outro lado, os cenários de caixa preta são criados para representar os cenários de mundo real fazendo referência a uma sequência diferente de fluxos gerados na sequência principal que representa o cenário. Essa etapa é muito importante para garantir que os requisitos, entendidos por meio da fase de análise de requisitos, sejam atendidos. Isso, por sua vez, nos ajuda a realizar a análise de suficiência dos tópicos detalhados e das operações que os cercam.

No caso de qualquer incompatibilidade, considera-se essencial voltar e mudar o modelo de informações até que as sequências funcionais desejadas do mundo real sejam alcançadas. Além disso, a obtenção da máquina de estado do caso de uso é bastante direta. A máquina de estado do caso de uso é composta por diversos estados ‘AND' com cada um representando o comportamento do estado dos fluxos funcionais independentes no diagrama de atividades. Enquanto cada um dos fluxos é representado por um estado AND e, dessa forma, é independente em sua execução, ainda assim são unidos por meio dos fluxos de evento de um estado AND para outro, aguarde os subestados para permitir a execução da máquina de estado como um todo. Isso é necessário para verificar as sequências geradas automaticamente por meio da execução do modelo com base nos cenários de caixa preta produzidos anteriormente.

Visualização maior da Figura 4.

Visualização maior da figura 5.

Visualização maior da figura 6.

Síntese de design

A decomposição estrutural do sistema nessa abordagem tem base não apenas na identificação das principais funções do sistema, mas também no modelo de tópico derivado. Além disso, a alocação de funções a partir do diagrama de atividade de caixa branca é realizada por meio da alocação independente de um fluxo completo a partir do diagrama de atividade de caixa preta para uma swimlane. Uma alocação como essa é possível devido à acessibilidade das instâncias e amostras de tópico derivadas entre limites de subsistema por meio do espaço de dados global DDS.

O diagrama de atividades de caixa preta derivado para o caso de uso é exibido na Figura 7. A funcionalidade alocada para a swimlane representando o espaço de dados DDS é a de costurar o restante dos componentes por meio do paradigma de publicação/assinatura. Essa representação é considerada necessária para unir os subsistemas a fim de participar em cenários do mundo real no nível do modelo e também dar vida à máquina de estado de caixa branca executável. A próxima etapa no processo é desenvolver os cenários de caixa branca para o caso de uso, representando a visualização de caixa branca dos cenários de caixa preta. Um cenário de caixa branca representativo é exibido na Figura 8.

Finalmente, nós obtemos as portas e interfaces a partir dos cenários de caixa branca e chegamos ao comportamento de estado de caixa branca dos componentes do subsistema em preparação para o hand-off. O comportamento de estado representativo e as portas e interfaces de caixa branca dos subsistemas são exibidos na Figura 9 e 10, respectivamente.

Os gráficos de estado do subsistema nesse caso, usam exatamente o mesmo padrão que os correspondentes de caixa preta. A única diferença entre os dois é que os eventos que acionam a transição a partir do estado de espera do subsistema são gerados pelo componente DDS-Data-space. A máquina de estado do componente DDS-Data-space é uma representação simulada a fim de permitir a execução de diferentes componentes desacoplados. As máquinas de estado de caixa branca são executadas para comparar os diagramas de sequência gerados com os cenários de caixa branca a fim de estabelecer uma linha de base do modelo para hand-off. Finalmente, as interfaces do subsistema com mapeamento claro para o modelo de tópico são geradas a partir do modelo de linha de base, como mostra a Tabela 5.

Visualização maior da figura 7.

Visualização maior da Figura 8.

Visualização maior da figura 9.

Visualização maior da figura 10.

Voltar para parte superior

Conclusão

A principal preocupação ao agrupar a arquitetura de um sistema distribuído com base em componente é poder definir sem ambiguidade as funções de negócio e suas interfaces entre os subsistemas. Podemos resolver adequadamente essas questões se o sistema aderir aos seguintes princípios de Arquitetura aberta da arquitetura orientada a serviços (SOA) (veja Recursos):

• Modularidade: isso implica em uma arquitetura que particionou cuidadosamente as funções de negócio e técnicas de uma forma que permita o acesso independente a elas com o mínimo de necessidade de manter o estado entre as interações. O uso do paradigma de publicação e subscrição no design de um sistema distribuído promove de forma inerente o uso da natureza sem estado do design do subsistema. Como fica evidente no caso de referência do documento, cada um dos fluxos de atividade independente representam naturalmente um estado AND do componente, enquanto o único estado predominante em cada estado AND é o estado de espera de cada fluxo. O comportamento fica amplamente sem estado depois disso, resultando na criação ou atualização de uma entidade definida, que por si só é exposta ao restante do sistema por meio de uma operação de gravação e nunca é preservada. Um design como esse naturalmente exibe as propriedades de um sistema modular que preserva o estado mínimo entre as interações.

• Padrões abertos: o uso de padrões abertos afeta mais o design do sistema distribuído onde esses padrões precisam lidar com a descrição de serviço, descoberta e acesso de funcionalidade. SysML é uma linguagem de modelagem com base em um padrão aberto, assim como a especificação DDS. SysML é a linguagem para definição clara da funcionalidade do sistema ou do subsistema. Embora DDS seja uma linguagem para definição clara de interfaces de subsistema, ela também encapsula magicamente os mecanismos de descoberta e acesso.

• Interoperabilidade: nos sistemas distribuídos, a interoperabilidade depende de uma sintaxe e semântica de interface bem definida. DDS, como uma linguagem de interface, não apenas expõe claramente a capacidade da interface com relação a o que ela faz, mas também a semântica e o comportamento relevante do modelo de dados. Isso não deixa escopo para interpretações equivocadas dos dados por meio da aplicação do contexto errado em sua interpretação.

Dessa forma, unir os dois ativadores, ou seja, DDS e SysML, em um processo MBSE parece definitivamente uma história de sucesso para a análise e design de sistemas distribuídos, uma que segue de perto o caminho definido por um processo maduro como a engenharia de sistemas do Rational Harmony, que tem base nas melhores práticas de engenharia de sistemas.

Recursos

Aprender

• Visite a área do software Rational no developerWorks para obter recursos técnicos e boas práticas para os produtos do Rational Software Delivery Platform.
  
  
• Fique por dentro doseventos técnicos e webcasts do developerWorks com foco em uma variedade de produtos IBM e tópicos do segmento de mercado de TI.
  • Participe de um briefing ao vivo e gratuito do developerWorks para se atualizar rapidamente sobre produtos e ferramentas IBM, bem como tendências do segmento de mercado de TI.
  • Acompanhe as demos on demand do developerWorks, variando de demos de instalação e configuração de produtos para iniciantes a funcionalidades avançadas para desenvolvedores experientes.
  
  
• Melhore suas qualificações. Consulte o Treinamento e certificação do Rational que inclui muitos tipos de cursos em uma ampla variedade de tópicos. É possível realizar alguns deles em qualquer local, a qualquer momento, e muitos dos cursos para iniciantes são gratuitos.
  
  
• Leia "Serviço de distribuição de dados para sistemas em tempo real, versão 1.2 "Especificação formal disponível de OMG /07-01-01.
  
  
• Systems Engineering Best Practices with the Rational Solution for Systems and Software Engineering por Hans Peter Hoffman; release impresso
  
  
• Leia, de Michael Jackson, "Problem Frames: Analyzing & Structuring Software Development Problems"
  
  
• Leia "Open Architecture Technical Principals and Guidelines 1.5.8" escrito por Eric M. Nelson.
  
  

Obter produtos e tecnologias

• Faça download de uma versão gratuita do software Rational.
  
  
• Avalie outros produtos de software da IBM da forma que melhor lhe convier: faça o download da versão de avaliação, experimente-a on-line, use-a em um ambiente de nuvem ou passe algumas horas no SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de forma eficiente.
  
  

Discutir

• Faça parte de fóruns do software Rational do Rational Asset Analyzer para fazer perguntas e participar de discussões.
  
  
• Classifique ou revise o software Rational. É rápido e fácil. Realmente.
  
  
• Compartilhe seu conhecimento e ajude outros a usar o software Rational, escrevendo um artigo para o developerWorks. Descubra quais são as características de um bom artigo do developerWorks e como realizá-lo.
  
  
• Siga o software Rational no Facebook, Twitter (@ibmrational) e no YouTubee adicione seus comentários e solicitações.
  
  
• Faça e responda a perguntas, e aumente seu conhecimento participando dos Fóruns do Rational, caféée wikis.
  
  
• Obtenha liderança em pensamento social. Faça parte da comunidade Rational para compartilhar seu conhecimento em software Rational e ficar conectado a seus colegas.
  
  

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Entenda o DDS e a análise de problem-frame
• Conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais