Pontos de Vista ArchiMate Práticos para a Camada de Aplicativos
Postado em 8 de ago. de 2018 por Antonio Plais
Originalmente postado por Bernd Ihnen*, no blog da BiZZdesign – Tradução autorizada
Em uma postagem anterior descrevemos porque é útil reduzir a complexidade quando criando diagramas da arquitetura. O mecanismo de pontos de vista, parte importante do padrão da linguagem ArchiMate, suporta o arquiteto através de orientações para a criação de diagramas, e suporta o leitor por não criar diagramas demasiadamente complexos (muitos tipos de conceitos diferentes). Cada ponto de vista endereça uma preocupação específica, por exemplo, um mapa de capacidades para mostrar quais são as capacidades da empresa. Nesta postagem vamos focar na camada de aplicativo para fornecer exemplos práticos usando o padrão de criação de pontos de vista descrito na postagem anterior. Os exemplos são bastante genéricos. Eles são destinados a serem usados com um ponto de partida para os profissionais que estão procurando aprender sobre o assunto, de forma que possam atingir uma audiência mais ampla.
Ponto de vista estrutural – Componentes de Aplicativo
Relacionamentos estruturais modelam a construção estática ou a composição de conceitos do mesmo tipo ou diferentes. O ponto de vista de componentes de aplicativo pode ser configurado para mostrar a hierarquia dos componentes de aplicativo, seus serviços de aplicativo e quais requisitos são realizados pelos (componentes de) aplicativos ou seus serviços. Você pode usar este ponto de vista para criar diagramas que mostrem simplesmente os componentes de um aplicativo. Neste caso, ele ajuda você a adicionar novos elementos ao seu modelo de uma forma orientada. Você também pode mostrar os requisitos que o novo (serviço de) aplicativo deve atender. O foco deste ponto de vista é em um aplicativo, não nas dependências ou no suporte para outros componentes de aplicativo. Ele é similar ao ponto de vista de estrutura de aplicativo mencionado na especificação do padrão ArchiMate, mas mais restritivo, focando na estrutura hierárquica de um aplicativo e mostrando quais requisitos o novo aplicativo deve realizar.
Comparado com o padrão ArchiMate completo, que inclui 59 conceitos e 13 tipos de relacionamentos, este ponto de vista permite apenas 3 conceitos diferentes e 2 tipos de relacionamento. Isto faz com que ele seja muito menos complexo e mais fácil de compreender. Um exemplo de uma visão de componentes de aplicativo é mostrado abaixo. No lado direito, fizemos uso de aninhamento gráfico baseado no relacionamento de composição para mostrar uma representação gráfica alternativa.
Ponto de Vista de Dependência – Cooperação de Aplicativo I
Relacionamentos de dependência modelam como elementos são usados para suportar outros elementos. Empregar o padrão de criação de pontos de vista neste caso permitirá a criação de pontos de vista de dependência no nível dos relacionamentos de servidão e acesso. As dependências entre os aplicativos são geralmente mostradas em visões de comunicação de aplicativo (TOGAF) ou cooperação de aplicativo (ArchiMate). Em resumo, eles mostram como a cooperação entre os aplicativos acontece. Isso pode ser expressado de uma forma estática mostrando os serviços de aplicativo (o que o componente de aplicativo faz) e os dados acessados. O exemplo abaixo mostra que o Payroll Service está acessando (lendo) o Employee Data quando servindo o componente de aplicativo SAP Finance.
Ponto de Vista Dinâmico – Cooperação de Aplicativo II
Relacionamentos dinâmicos modelam as dependências comportamentais entre elementos. Os dois tipos de relacionamento são fluxo e acionamento. Em geral, acionamento é usado entre processos, enquanto que na camada de aplicativo nós normalmente vemos fluxo sendo usado entre componentes de aplicativo. Como uma alternativa para o ponto de vista explicado acima, você pode usar o relacionamento de fluxo para criar um diagrama de cooperação de aplicativo de uma forma ligeiramente diferente. Ao não usar o serviço de aplicativo você esconde informação, mas isso pode ser uma vantagem quando você quer mostrar um fluxo de dados ponta-a-ponta para um objeto de dados através do seu panorama de aplicativos. Estes diagramas podem envolver muitos aplicativos, de forma que não mostrar quais serviços acessam quais dados permite manter o diagrama menos complexo. No exemplo abaixo, usamos também o relacionamento de associação, usado para indicar o objeto de dados associado com o relacionamento de fluxo (permitido desde o ArchiMate 3).
Sumário e Possíveis Extensões
Vamos recapitular. Aplicamos os padrões descritos em nossa postagem anterior para criar pontos de vista ArchiMate na camada de aplicativo. O padrão é muito útil para decidir quais elementos e relacionamentos são permitidos em qual diagrama. Sem um padrão como este, você sempre vai encontrar alguma justificativa para permitir um conceito ou relacionamento em uma visão e não em outra. Desta forma, o uso destes padrões economiza tempo quando discutindo quais tipos de diagrama devem ser criados de forma padrão nos projetos.
Estes pontos de vista também fornecem implicitamente uma ordem para a criação dos elementos e relacionamentos. Normalmente é mais útil mostrar primeiro os componentes e/ou serviços de um novo aplicativo e porque eles são necessários. Declarando porque um novo aplicativo ou um novo serviço é necessário suporta você na ‘venda’ da sua arquitetura, por exemplo, em uma apresentação para a gerência. Ao criar esta visão, você adiciona novas informações ao repositório de uma forma orientada. As visões de cooperação de aplicativo, então, mostram o contexto do seu novo aplicativo – onde ele impacta no panorama de aplicativos existente.
Uma adição útil a um ponto de vista de cooperação de aplicativo é mostrar qual interface de tecnologia é usada (e.g. REST API, FTP, WebService). Especialmente no ponto de vista de cooperação de aplicativo dinâmico, com os relacionamentos de fluxo, você pode criar uma convenção governando quantos relacionamentos de fluxo são permitidos entre aplicativos. Adicionar um relacionamento de fluxo para cada objeto de dados lhe dá a opção de adicionar propriedades como frequência de troca, indicação de iniciação do fluxo (puxado/empurrado), e outras, mas também pode levar a diagramas extremamente sobrecarregados. Uma alternativa é criar apenas um relacionamento de fluxo para cada tecnologia de interface. Para uma visão geral isto pode ser bom o suficiente para guiar o desenvolvimento da arquitetura. Como um diagrama complementar para o desenho mais detalhado da solução no projeto, você poderia usar diagramas de sequência UML que mostram em detalhes os fluxos de dados entre os aplicativos (incluindo mensagens de confirmação que possam ser importantes para o desenho da solução, mas que não são úteis no nível mais alto da arquitetura). E, naturalmente, você não quer poluir seu diagrama adicionando todos os conceitos e relacionamentos. Ao invés disso, você pode usar cores e etiquetas para mostrar informações do modelo de arquitetura, como mostrado no exemplo abaixo:
A tabela resumida abaixo mostra os três pontos de vista apresentados acima. Você pode querer criar pontos de vista adicionais para a camada de aplicativo – por exemplo, para arquiteturas lógicas, usando o conceito de função de aplicativo ao invés do componente de aplicativo. Sinta-se à vontade para tentar este padrão de criação de pontos de vista por você mesmo, ele é uma orientação forte e útil!
Em uma próxima postagem mostraremos este padrão de criação de pontos de vista nas camadas de negócios e de tecnologia. Então, fique ligado e, enquanto isso, dê uma olhada em uma postagem de Marc Lankhorst onde ele posiciona os desenhos arquiteturais como uma das três metas quando comunicando a mudança para as suas partes interessadas.
* Bernd Ihnen é Consultor e Instrutor da Bizzdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.
eBook
Pensando em Processos
Muitos livros foram escritos sobre o tema do BPM. A maioria, no entanto, se concentra em aspectos específicos neste domínio, tornando difícil obter uma boa visão geral do BPM. Parece também que muitas pessoas têm dificuldade em configurar o BPM dentro de sua organização: por onde começar? Estes problemas são destacados neste livro. As questões […]