Projete e implemente uma fábrica de softwares

Resumo

Nessa abordagem da interoperabilidade, compartilhamos a experiência obtida no projeto e na implementação de uma fábrica de softwares para sistemas de assistência médica com base no padrão HL 7 (Health Level Seven).

Discutimos a visão de longo prazo e a prova de conceito de escopo reduzido desenvolvidos até agora. Também destacamos os desafi os encontrados no nosso projeto e as oportunidades para ampliar o escopo da abordagem para setores diferentes e, em geral, as oportunidades para apoiar a colaboração de empresa para empresa.

O objetivo aqui é compartilhar a experiência obtida na hora de projetar e implementar uma fábrica de software baseada em HL7, um padrão de interoperabilidade entre as organizações de assistência médica. Começamos o trabalho há quase um ano com a especificação de alto nível da fábrica, produzindo uma primeira versão de seu esquema e da arquitetura de solução (consulte Recursos).

Em sua fase inicial, a fábrica se voltou para o projeto das portas de colaboração HL7, que são sistemas projetados para implantação à margem dos sistemas de TI das organizações de assistência médica, e permitir que os aplicativos de assistência médica colaborem em conformidade com os protocolos comerciais e técnicos padronizados na HL7 Versão 3, usando uma infra-estrutura de comunicação baseada no serviço da Web.

Na segunda fase, implementamos uma primeira versão – de escopo reduzido – da fábrica HL7 especificada na primeira fase. O foco dessa versão é o subconjunto dos recursos da porta de colaboração HL7 necessários para permitir a comunicação entre os aplicativos de assistência médica por meio de adaptadores do serviço da Web, em conformidade com os perfi s do serviço da Web HL7 (consulte Recursos).

O escopo completo da fábrica, conforme especifi cado, também incluía o desenvolvimento dos adaptadores de integração dos aplicativos empresariais para conectar os aplicativos existentes às portas de colaboração e a orquestração das trocas de mensagens comerciais, percebendo uma colaboração em particular em prol dos aplicativos de linha de negócios que não foram projetados para a colaboração.

Figura 1 - O contexto de produção de uma fábrica HL7

Nossa experiência em projetar e desenvolver a fábrica HL7 mostra-se valiosa de duas perspectivas diferentes. Ao desenvolver a fábrica HL7, encontramos alguns desafi os para desenvolver o esquema da fábrica, gerenciar a sua confi guração, compreender como seriam usadas as linguagens específi cas de domínio e promover as ferramentas disponíveis no momento no ambiente de desenvolvimento.

Figura 2 - O contexto de desenvolvimento de uma fábrica HL7

Ao mesmo tempo, percebemos que o escopo da fábrica poderia ser ampliado da colaboração entre os aplicativos de assistência médica baseados no HL7 para uma noção mais genérica de colaboração entre os aplicativos baseados em especifi cações padronizadas (ou compartilhadas).

Portanto, atualmente estamos em vias de generalizar a abordagem comprovada na implementação inicial da fábrica HL7 para projetar e desenvolver o que chamamos de fábrica de colaboração comercial.

Fábricas de software

As fábricas de softwares usam conhecimento de domínio específico, arquiteturas de solução, ferramentas e outros ativos reutilizáveis para ajudar os usuários a produzir tipos específi cos de soluções de softwares. As fábricas se baseiam em três idéias principais: um esquema de fábrica de software, um modelo de fábrica e um ambiente extensível de desenvolvimento.

A fábrica configura um ambiente extensível de desenvolvimento, como Eclipse, Borland JBuilder ou Microsoft VSTS (Visual Studio Team System), usando um pacote instalável chamado modelo de fábrica de software ou pacote de orientação. Quando confi gurado dessa maneira, o ambiente de desenvolvimento torna-se um mecanismo especializado que acelera o desenvolvimento de um tipo específi co de solução de software, como uma interface de usuário ou uma camada de acesso de banco de dados, ou talvez um aplicativo inteiro em um domínio de negócio como a assistência médica ou a segurança privada.

O modelo de fábrica de software é organizado por um modelo chamado esquema de fábrica de software. O esquema defi ne um ou mais pontos de vistas relevantes para os interessados na produção das soluções almejadas de softwares. Cada ponto de vista defi ne os artefatos do ciclo de vida produzidos ou consumidos por seus interessados, as atividades que eles realizam em relação a esses artefatos e os ativos reutilizáveis para suportá-los na hora de realizar essas atividades.

A metodologia da fábrica de softwares integra o MDD (Desenvolvimento Dirigido pelo Modelo), o CBD (Desenvolvimento Baseado em Componente) e as práticas ágeis de desenvolvimento, incluindo a utilização de padrões e linguagens de padrão com modelos, estruturas e ferramentas (consulte Recursos).

Para promover os modelos com efi ciência para várias formas de automatização, as fábricas fazem um uso intenso das DSLs (Linguagens para Domínio Específi co). A tecnologia DSL é muito mais recente do que a maioria das outras tecnologias usadas nas fábricas de softwares, baseando-se nas famílias de linguagens extensíveis. As ferramentas e estruturas de desenvolvimento de DSL já estão em desenvolvimento há algum tempo nos círculos acadêmicos, mas sua aparição na forma de negócio é muito recente (consulte Recursos).

A fábrica HL7 automatiza o desenvolvimento dos sistemas chamados de portas de colaboração, que permite a interoperação entre os sistemas no domínio de assistência médica. Especifi camente, as soluções produzidas pela fábrica visam a:

Figura 3 - Ponto de vista da produção do sistema

• Perceber as interações defi nidas pelo padrão HL7 como trocas de informações que ocorrem entre os aplicativos em resposta aos eventos de acionador. Coletivamente, essas trocas suportam os objetivos de negócio de um caso de uso específi co, como a realização da observação em laboratório. A fábrica automatiza a produção do código que implementa essas interações, minando as informações contidas no HL7 RIM (HL7 Reference Information Model).

• Permitir a colaboração de negócio de aplicativo para aplicativo expressa em termos dessas interações sobre uma infra-estrutura de serviço da Web, baseada em padrões abertos, que está em conformidade com um subconjunto dos perfi s de serviço da Web do HL7 V3, a saber, os tópicos Básico, Direcionamento, Segurança e Mensagens confi áveis (consulte Recursos).

• Permitir a integração dos aplicativos novos ou existentes que não foram projetados: 1) para o HL7, versão 3; 2) para atender aos propósitos da colaboração comercial; e 3) para se comunicar em uma infra-estrutura de serviço da Web.

É importante entender a fábrica HL7 de duas perspectivas diferentes: de produção e desenvolvimento. No contexto de produção, os produtos fi nais da fábrica são as portas de colaboração HL7. Essas portas permitem automaticamente que aplicativos diferentes de assistência médica colaborem por trás do fi rewall usando os serviços da Web, já que pelo menos um dos aplicativos que participam da colaboração de negócio implantará uma porta de colaboração HL7; os outros aplicativos podem participar por outros meios, e todos os aplicativos que participam da colaboração de negócio estarão em conformidade com os padrões HL7 V3 para a troca de mensagens, ou de forma nativa, ou com a ajuda de uma porta de colaboração HL7.

Fábrica por modelo

Para uma colaboração de negócio entre um hospital e um laboratório, a Figura 1 mostra onde as portas de colaboração HL7 se situam em relação aos sistemas que hospedam os aplicativos de interoperação. Observe que as portas de colaboração devem ser altamente confi guráveis para permitir a expedição geral, permitindo também uma orquestração complexa no fl uxo das mensagens. Assim, portas como as mostradas na Figura 1 são confi guradas em termos dos detalhes técnicos para uma implementação e implantação específi cas e em termos das defi nições de domínio e dos níveis de conformidade do padrão HL7.

Figura 4 - Ponto de vista do projeto de contrato de softwares

No contexto do desenvolvimento, o objetivo da fábrica de softwares é acelerar a especifi cação e a implementação das portas de colaboração. A fábrica combina o conhecimento de domínio do problema fornecido pelo HL7 RIM e pelos perfi s de serviços da Web, com o conhecimento da tecnologia de plataforma, da arquitetura de solução e do processo de desenvolvimento fornecido pela documentação da plataforma e pelos desenvolvedores da fábrica (consulte a Figura 2).

Como sugerido pela ilustração, esse conhecimento é empacotado em ativos numerosos, que formam, coletivamente, o modelo da fábrica. Colocado a questão de forma simples, o modelo de fábrica fornece tudo o que for necessário para construir uma porta de colaboração HL7, incluindo dados e artefatos de referência, tais como esquemas de mensagens; ferramentas, como geradores de adaptadores; e orientação do processo. O modelo de fábrica deve ser instalado em um IDE, a saber, Microsoft Visual Studio 2005 Team System, antes que possa ser usado para produzir e implantar portas de colaboração HL7.

Como foi anteriormente observado, o objetivo aqui é descrever o que aprendemos na especifi cação, no projeto e na implementação da fábrica HL7. Agrupamos as informações em duas categorias. A primeira classifica as lições aprendidas no desenvolvimento e na utilização da fábrica em geral; a segunda contém idéias obtidas em relação ao domínio principal e a como a fábrica pode ser generalizada para dar conta de uma gama mais ampla de domínios principais.

O desenvolvimento e o gerenciamento do esquema da fábrica foram os desafi os mais signifi cativos desde a concepção do projeto até sua conclusão. Produzir uma versão inicial do esquema foi algo relativamente fácil (consulte Recursos). Nessa fase, é possível usar com efi cácia uma abordagem baseada em grade, organizando os pontos de vistas relevantes em uma matriz bidimensional com o nível de abstração no eixo vertical e a fase do ciclo de vida no eixo horizontal.

No entanto, rapidamente nos demos conta de que a matriz bidimensional era uma representação bastante inadequada do esquema, especialmente para a versão de escopo completo da fábrica porque: a) o esquema era naturalmente multidimensional; b) a representação de matriz não captura as relações entre pontos de vistas não adjacentes; c) os gráfi cos dos pontos de vistas foram de tipos e profundidades diferentes e se desdobraram em gráfi cos aninhados de tipos e profundidades diferentes.

Não obstante, trabalhar com uma representação amorfa baseada em gráfi co do esquema exigiu ferramentas que não estavam disponíveis. Portanto, implementamos o esquema de fábrica como um conjunto de projeções bidimensionais dos pontos de vistas relevantes. Cada uma dessas projeções – um gráfi co em seu próprio sentido – detalha um aspecto específi co da fábrica, projetando-o com efi cácia a partir do esquema multidimensional da mesma maneira que um conjunto de tuplas é projetado de um armazenamento de dados multidimensionais para formar uma imagem bidimensional.

Por exemplo, as Figuras 3 e 4 mostram dois exemplos de pontos de vista, a saber, o ponto de vista do Desenvolvimento do sistema, e um aspecto particular dele: o Projeto de contrato de Software – a um nível inferior de abstração.

Figura 5 - A seleção de casos de uso do assistente de configuração

Atribuindo tarefas

Essa abordagem nos permitiu produzir uma versão do esquema de fábrica que consideramos completa, ou seja, especifi cou de forma abrangente todos os artefatos e ferramentas necessários no modelo de fábrica para produzir os produtos da fábrica. No entanto, ela deixou a verifi cação do esquema para a inspeção humana, não nos permitindo usar o esquema como metadados para orientar a experiência do usuário dentro do IDE.

O gerenciamento de confi guração foi outro aspecto desafi ador do desenvolvimento de fábrica, de duas perspectivas diferentes.

Em primeiro lugar, tivemos que criar um esquema XML de confi guração, que estaria completo em termos de permitir a expressão de todas as combinações válidas dos recursos aceitos e/ou das estratégias de implementação. O esquema XML foi idealizado à mão e rapidamente se tornou um fardo de manutenção, uma vez que foi altamente sensível às mudanças no esquema e no modelo de fábrica.

Em segundo lugar, não tínhamos ferramentas no ambiente-alvo de desenvolvimento para suportar a confi guração de uma instância específi ca da fábrica, ou a validação de tal confi guração, durante o desenvolvimento do produto.

A especificação do processo de desenvolvimento do produto também foi um desafi o na hora de desenvolver a fábrica. Não contávamos com nenhuma forma satisfatória de expressar formalmente o processo no modelo de fábrica, e, mais importante, nenhuma maneira de injetar o processo enquanto orientação prescritiva no ambiente de desenvolvimento.

Embora o ambiente-alvo de desenvolvimento não suporte a criação de tarefas nem a atribuição das tarefas aos membros da equipe de desenvolvimento, tínhamos que confi ar em documentos em linguagem natural para descrever o processo de desenvolvimento, pois ainda não tínhamos determinado como aplicar os recursos de gerenciamento de tarefas a um processo de desenvolvimento de produtos baseado em fábrica. Em particular, ainda não tínhamos determinado como associar as tarefas com ativos específi cos fornecidos pelo modelo de fábrica, como carregar essas tarefas do modelo ou como confi gurar as tarefas para um produto específico.

Também achamos bastante difícil decidir se devíamos fornecer ou não uma DSL bem-desenvolvida para a fase de levantamento de requisitos do desenvolvimento de produtos, em especial porque a Microsoft publicou um conjunto de ferramentas DSL sob o guardachuva de sua Software Factories Initiative.

Sabíamos que uma DSL completa não era estritamente necessária, pois as especifi cações relevantes do caso de uso já nos eram disponíveis no repositório HL7. O que realmente precisávamos era de um assistente sofi sticado que ajudaria o usuário a escolher os casos de uso específicos (consulte a Figura 5), as funções do aplicativo, os padrões de interação de serviço (consulte a Figura 6) e outros elementos padronizados de dados, e a navegar pelo repositório.

Além disso, a tecnologia do projetista da DSL oriunda da Microsoft ainda estava muito crua quando começamos o projeto, e sua adoção teria acrescentado um risco signifi cativo ao projeto. Embora soubéssemos que estávamos perdendo a oportunidade de fornecer mais automatização sofi sticada, e que a alternativa – uma interface de usuário baseada em assistente – não seria relevante fora do escopo da fábrica, decidimos não usar a tecnologia DSL nessa fase do projeto.

Como agora temos uma previsão tecnológica muito mais consolidada e robusta das ferramentas DSL, podemos começar a experimentar as DSLs nas versões subseqüentes da fábrica. Além disso, mesmo que tivéssemos decidido criar outra interface de usuário baseada em assistente, provavelmente a teríamos projetado e implementado usando as ferramentas DSL, em vez de tê-la desenvolvido a partir do zero.

O GAT (Guidance Automation Toolkit), outro estágio de ativação de tecnologia no guarda-chuva da Software Factories Initiative da Microsoft, se mostrou bastante útil.

Em termos simples, o GAT é uma extensão do ambiente de desenvolvimento que facilita a criação de experiências valiosas e integradas do usuário em torno de ativos reutilizáveis como estruturas, componentes e padrões. Os pacotes resultantes de orientação são compostos de modelos, assistentes e receitas que ajudam os usuários a desenvolver soluções ao se manterem com a orientação arquitetural predefinida.

Ampliar o escopo

No nosso projeto, usamos o GAT como meio de empacotar e fornecer o modelo de fábrica. Ele forneceu um modelo subjacente para o modelo que era muito mais valioso do que o que o próprio ambiente de desenvolvimento tinha para oferecer.

As receitas foram fornecidas para as atividades como a criação do Adaptador de serviços da Web HL7, a execução do assistente de configuração, a criação de contratos de serviços da Web e a automatização do processo de criação de código.

Infelizmente, a curva de aprendizagem do GAT é bastante acentuada. Suas opções de fl exibilidade e personalização são limitadas, e sua integração com o IDE poderia ter sido melhor. No entanto, acreditamos que a adoção do GAT era uma decisão importante que nos ajudou a garantir o sucesso do projeto e reduziu signifi cativamente o tempo de desenvolvimento da fábrica.

Figura 6 - A especifi cação dos padrões de interação de serviço do assistente de configuração

Embora tivéssemos desenvolvido a fábrica para permitir a colaboração de uma empresa com a outra entre os aplicativos de assistência médica, rapidamente fi cou claro que poderíamos aplicar uma fábrica assim a cenários semelhantes em outros setores. Conseguíamos entender que o escopo real da fábrica devia ser a colaboração de negócio em geral, usando especifi cações padronizadas ou predefi nidas de interações, funções de aplicativos, eventos, perfi s de serviços da Web e outros elementos de domínio, e não apenas a colaboração de negócio no contexto do HL7.

Em retrospectiva, a razão pela qual inicialmente desenvolvemos uma fábrica para o HL7 era que o padrão HL7 fornecia um conjunto completo de elementos de domínio bem-defi nidos e de fácil acesso. Naturalmente, muitos outras organizações de padrões, como a RosettaNet e a UNCEFACT, também investiram muitos esforços para especifi car elementos de domínio a serem usados pelas empresas que desejam colaborar usando protocolos padronizados. O que é realmente interessante, no que tange aos protocolos de colaboração e às informações que trocam, é que esses padrões são muito parecidos entre si.

Assim, concluímos que seria possível não apenas desenvolver sistemas de colaboração baseados em padrões para outros setores, como também desenvolver uma fábrica de portas de colaboração que pode ser personalizada usando-se especifi cações de colaboração de negócio para outros setores da economia. Naturalmente, serão necessários vários mecanismos de importação, adaptadores e conversões de modelos que permitam o funcionamento de conceitos diferentes usados para descrever a colaboração de uma empresa a outra por entidades diferentes de padrões. No entanto, achamos que uma especifi cação genérica poderia ser usada para criar uma ponta entre essas diferenças por meio da configuração em uma fábrica genérica de colaboração comercial.

Ao mesmo tempo, reconhecemos que uma fábrica mais genérica também pode ter um apelo bastante interessante junto aos desenvolvedores corporativos que estão construindo sistemas de colaboração de negócio dentro do fi rewall, e aos que desejam contar com uma abordagem mais formal para especifi car e implementar esses sistemas para garantir o melhor alinhamento entre as metas comerciais e um portfólio de serviços de TI resultantes. No entanto, nesse caso, precisaríamos fornecer aos arquitetos empresariais os modelos e as ferramentas necessários para suportar o processo de especificação.

Percebemos que nossa fábrica deve aceitar a construção de portas de colaboração para várias plataformas de tecnologia. Suspeitamos que isso poderia ser realizado com padrões de implementação fornecidos com o modelo de fábrica para encerrar o vínculo entre a especifi cação das portas de colaboração e os detalhes de implementação específi cos da plataforma.

Assumindo a dianteira

Nossos planos são explorar a oportunidade descrita aqui para generalizar a fábrica HL7 e formar uma fábrica de colaboração comercial. Acreditamos que boa parte do trabalho necessário para conseguir essa generalização se encontrará nestas áreas:

• Fornecer modelos e ferramentas para suportar a especifi cação das colaborações de negócio, focando-se no esquema de informações, nos protocolos de troca de mensagens e documentos de negócio e, possivelmente, nas transações de negócio.

• Definir os mapeamentos entre os padrões industriais relevantes e nosso modelo interno de colaboração de negócio, e possivelmente as ferramentas para importar os elementos de domínio que eles definem.

• Apresentar outro nível de confi guração na implementação da porta de colaboração que permitirá que os usuários da fábrica tenham como objetivo uma variedade mais ampla de plataformas de tecnologia.

Nossa experiência no desenvolvimento de uma fábrica para as portas de colaboração HL7 demonstra que precisamos defi nir estruturas, ferramentas e processos melhores para especifi car o esquema da fábrica, gerenciar a confi guração da fábrica de uma forma fl exível e extensível e compreender melhor como e quando se devem usar as linguagens específi cas de domínio. Ao mesmo tempo, as implementações iniciais de mecanismos de extensão, como o GAT e a DSL, provaram seu valor, preenchendo lacunas signifi cativas na infra-estrutura da fábrica de softwares e apontando para inovações futuras nessa área.

Pretendemos continuar usando e aprimorando essas ferramentas na próxima versão da fábrica HL7, bem como na versão mais genérica e de vários setores, chamada de fábrica de colaboração comercial.

Sobre os autores

Mauro Regio é arquiteto de soluções industriais na equipe de estratégia de arquitetura do parceiro e do desenvolvedor na Microsoft, voltado para projetos e fábricas de softwares de integração de negócio de larga escala.

Jack Greenfield é arquiteto de softwares e ferramentas empresariais na Microsoft.