VII Simpósio Brasileiro de Sistemas de Informação
Identificação de Interesses Transversais na Arquitetura
Empresarial
Trabalho de Mestrado
Fabiana Jack Nogueira Santos (Aluno), Flávia Maria Santoro (Orientadora),
Claudia Cappelli (Co-orientadora)
PPGI - Programa de Pós-Graduação em Informática
Departamento de Informática Aplicada – Universidade Federal do Estado do Rio de
Janeiro (UNIRIO)
Av. Pasteur, 458 – Rio de Janeiro – RJ – Brazil
{fabiana.nogueira, flavia.santoro, claudia.cappelli}@uniriotec.br
Ano de Ingresso no Programa de Mestrado: 2010
Época esperada de conclusão: Março de 2012
Etapas concluídas da pesquisa: Defesa da proposta
Abstract. The artifacts generated during the development of Information
Systems can be organized in a structured way through the approaches
proposed by the Enterprise Architecture, in particular, the Zachman
Framework. However the way these artifacts are generated and organized only
reflects the relational view between them, ignoring the fact that some features
crosscuts more than one artifact. The purpose of this paper is to explicitate
these characteristics in the Enterprise Architecture using the concepts of
Aspect Oriented approach.
Resumo. Os artefatos gerados durante o desenvolvimento de Sistemas de
Informação podem ser organizados de forma estruturada, através das
abordagens propostas pela Arquitetura Empresarial, em especial, o
Framework de Zachman. Porém, a forma como estes artefatos são gerados e
organizados reflete apenas a visão relacional existente entre eles,
desconsiderando o fato de que algumas características são transversais a
mais de um artefato. A proposta deste trabalho é explicitar tais características
na Arquitetura Empresarial utilizando os conceitos da abordagem Orientada
a Aspectos.
Palavras-chave: Arquitetura Organizacional de Tecnologia da Informação,
Matriz de Zachman, Interesses Transversais.
1. Introdução
O desenvolvimento de sistemas de informação é composto por diversas atividades:
levantamento de requisitos, análise de requisitos, projeto, implementação, testes e
implantação [Bezerra 2003]. Na etapa de levantamento de requisitos é compreendido o
421
VII Simpósio Brasileiro de Sistemas de Informação
problema e as necessidades dos futuros usuários para o qual o sistema será desenvolvido.
O resultado desta fase é o documento de requisitos, cujas principais informações são os
requisitos funcionais, não funcionais e restrições impostas sobre o desenvolvimento.
Na codificação de sistemas, [Kiczales et al. 1997] perceberam que alguns
requisitos, apesar de se repetirem, não eram modularizados de forma adequada, nem com
o paradigma da orientação a objetos, nem com o paradigma procedural. O código
referente a tais requisitos se encontrava disperso em vários trechos do código ou trechos
de código referentes a determinados requisitos se encontravam misturados com outros.
Estes problemas são denominados, respectivamente, espalhamento e intrusão [Tirelo et
al. 2004]. Estes requisitos foram denominados requisitos transversais. [Kiczales et al.
1997] propuseram a POA (Programação Orientada a Aspectos) para resolver o problema
da baixa modularidade dos requisitos transversais que dificulta a geração, manutenção e
evolução de código. Assim, é possível pensar sobre diferentes interesses de forma
isolada, tornando-os passíveis de remoção, possibilitando seu desenvolvimento de forma
separada, aumentando as possibilidades de reuso, permitindo que o desenho e a
codificação reflitam a forma como os desenvolvedores pensam sobre o sistema [Kiczales
et al. 1997], [Elrad et al. 2001] e diminuindo o custo de desenvolvimento, manutenção e
evolução [Rashid et al. 2003]. Os Aspectos são abstrações que permitem a
modularização dos interesses transversais que atravessam todo o código de um sistema
[Tirelo et al. 2004].
O conceito de Aspectos também foi incorporado em outras fases do
desenvolvimento de software, gerando assim o DSOA (Desenvolvimento de Software
Orientado a Aspectos) [Filman et al. 2005]. Nesta abordagem, são definidas novas
abstrações e mecanismos de composição entre as representações existentes e os
Aspectos. Com isso, a separação de interesses permeia todas as fases do
desenvolvimento de software [Cappelli et al. 2010a], porém cada uma das fases trata os
interesses transversais com foco específico, relacionando uma ou mais fases do
desenvolvimento [Silva e Batista 2006], [Medeiros 2008], mas desconsiderando o fato
de que tais interesses permeiam e evoluem, de forma contínua, em todas as fases e
produtos do desenvolvimento de softwares que apoiam as atividades organizacionais.
As abordagens Orientadas a Aspectos propõem formas de representar os
interesses transversais limitadas ao seu escopo ou fases no desenvolvimento de SIs. Por
exemplo, na Engenharia de Requisitos temos diversas propostas para representar os
interesses transversais, como Segurança, mas estas propostas não atentam para o fato de
que a definição do interesse transversal Segurança terá reflexos em diversos
componentes do sistema que implementará tal interesse e na organização que utilizará tal
sistema. Desta forma, os artefatos gerados pelas fases do desenvolvimento de SIs
possuem os interesses transversais embutidos e repetidos. O problema a ser endereçado
por este trabalho é que SIs possuem características transversais não explicitadas,
dificultando a manutenção e o entendimento dos próprios SIs.
A Arquitetura Empresarial ou Arquitetura Corporativa de TI é “o conjunto
estruturado de dados e modelos descritivos que definem o negócio, a informação e a
tecnologia suportada para operar a empresa, num processo contínuo de alinhamento com
o negócio” [Botto 2004]. Por sua definição a Arquitetura Empresarial engloba os
422
VII Simpósio Brasileiro de Sistemas de Informação
artefatos gerados pelo desenvolvimento dos SIs que darão suporte ao negócio da
organização, desde o nível mais estratégico até o próprio sistema em funcionamento.
A hipótese deste trabalho é que, se a representação das características
transversais for feita no nível da Arquitetura Empresarial, então os relacionamentos
existentes entre os diversos artefatos que possuem interesses transversais serão
explicitados. Quando as características transversais são identificadas em fases
preliminares, como será o caso ao explicitarmos as características transversais no nível
da Arquitetura Empresarial, a determinação do mapeamento e da influência nos demais
artefatos gerados no desenvolvimento dos SIs é facilitada [Rashid et al. 2003].
2. Proposta e enfoque de solução
Para ilustrar a proposta de solução deste trabalho utilizaremos um dos frameworks de
Arquitetura Empresarial, denominado Framework de Zachman. Este framework foi
inicialmente proposto em 1987, quando John Zachman indicava que a evolução
tecnológica permitiria que os sistemas se tornassem cada vez mais complexos e
distribuídos. Esta evolução torna necessário o uso de alguma estrutura arquitetural ou
lógica para a definição e controle das interfaces e integração de todos os componentes
dos SIs a serem gerados [Zachman 1987]. O objetivo de Zachman era assegurar que a
construção de sistemas corporativos fosse feita “de forma clara, fácil de entender,
equilibrada e completa” [Botto 2004] através do uso de sua arquitetura.
A Figura 1 apresenta o Framework de Zachman. Nesta matriz, as linhas
representam as diferentes perspectivas através das quais se pode observar uma empresa,
ou seja, são tipos de visões organizacionais. As colunas são as diferentes áreas de
interesse da visão organizacional [Botto 2004].
Figura 1. Framework de Zachman [Cappelli et al. 2010a]
Cada célula da matriz de Zachman (por exemplo, Modelo de Processos de
Negócio) é parte de um conjunto de artefatos necessários para representar um nível de
abstração (Modelo Organizacional) e ao mesmo tempo, também é parte componente de
uma perspectiva (Função - Como), estando relacionada com a célula superior (Lista de
Processos de Negócio) e inferior (Modelo de Arquitetura de Sistemas). Estes
relacionamentos possuem uma visão relacional [Cappelli et al. 2010a], onde os artefatos
se complementam, mas não apresentam partes em comum, desta forma, as características
que são transversais aos artefatos se encontram espalhadas e entrelaçadas, não havendo
uma forma de explicitá-las.
423
VII Simpósio Brasileiro de Sistemas de Informação
Para fins de ilustração, vejamos um exemplo: uma empresa atua na venda de
combustíveis em todo o país e surge uma nova legislação que obriga a implantação da
emissão eletrônica de notas fiscais. Esta mudança impacta a Arquitetura Empresarial
como um todo, pois a nova legislação deverá estar presente no Modelo de Arquitetura
de Sistemas (o sistema de faturamento precisará implementar a especificação imposta
pelo governo); na Arquitetura de Rede da empresa(o sistema de faturamento terá que se
comunicar com os sistemas dos órgãos fiscais para receber autorização para emissão das
notas); nos Processos de Negócio (devem refletir a mudança na forma como as notas
fiscais são emitidas); na Lista da Localização das Unidades de Negócio(cada unidade
federativa pode ter determinada autonomia com relação aos campos propostos pelo
governo para comporem a nota eletrônica); na Lista de Objetivos e Estratégias de
Negócio (a forma de fazer negócio pode ser alterada, já que os clientes não receberão
mais nota fiscal em papel); na Arquitetura de Segurança (a nota fiscal eletrônica deve
possuir uma assinatura digital que identifique a empresa) etc.
No exemplo acima fica claro que existem interesses que impactam mais de uma
célula da matriz ou que impactam grande parte da Arquitetura Empresarial. Portanto,
fica evidenciado que a visão relacional entre os artefatos da Arquitetura Empresarial não
resolve o problema dos interesses transversais.
Na Figura 2 é apresentada a matriz de Zachman acrescida de uma terceira
dimensão, onde será possível representar as características transversais, como segurança,
atuação econômica, legislação e quaisquer interesses que afetam mais de uma célula da
matriz.
Figura 2. Matriz de Zachman acrescida da dimensão Aspectual
[Cappelli et al. 2010a] citam um exemplo utilizando o Aspecto da Segurança.
Neste exemplo, a característica transversal da Segurança é representada na terceira
dimensão ilustrada na Figura 2 e é integrada aos artefatos da matriz. Quando
relacionamos a célula da matriz Pessoas – Quem com o Modelo Organizacional,
obtemos o artefato Modelo de Fluxo de Trabalho que é também afetado pela Segurança.
Ao conseguirmos representar as características transversais separadamente dos artefatos,
se torna possível a reutilização, já que o artefato se tornará mais independente e obterá
determinadas características apenas quando for “costurado” com a terceira dimensão.
O enfoque de solução a ser adotado neste trabalho é a identificação de possíveis
interesses transversais no nível da Arquitetura Empresarial, através de pesquisas na
literatura, de relatos de implantações da Arquitetura Empresarial e de análise de pacotes
de software destinados a atender negócios específicos; descoberta de formas para
424
VII Simpósio Brasileiro de Sistemas de Informação
representação dos interesses transversais identificados; busca por ferramentas que
apoiem a representação especificada; elaboração do método a ser seguido por arquitetos
para identificar e representar as características transversais em suas organizações.
O trabalho encontra-se na fase de identificação dos interesses transversais à
Arquitetura Empresarial, com elaboração de um exemplo gráfico do resultado da
explicitação das características transversais. Para tal, foi escolhida parte da matriz de
Zachman (uma coluna) e todas as células desta coluna foram analisadas para gerar o
exemplo de instanciação destas células.
3. Trabalhos relacionados
Na literatura existem diversas abordagens para representar os interesses transversais nos
Requisitos [Yu et al. 2004], [Rashid et al. 2003], nos Processos de Negócio [Cappelli et
al. 2010b], [Charfi 2007], [Park et al. 2007] e até em mais de uma fase do
desenvolvimento de SIs [Medeiros 2008], [Silva e Batista 2006]. Porém nenhuma destas
abordagens trata os interesses transversais nas fases iniciais de definição dos SIs
utilizando a abordagem da Arquitetura Empresarial com foco em todos os sistemas da
organização.
[Cappelli et al. 2010a] afirmam que os SIs possuem características transversais e
fornecem exemplos desta afirmação. Os autores indicam que é necessário identificar os
interesses transversais em nível organizacional, representá-los de forma explícita e
manipulável e permitir sua integração com outras perspectivas. Os autores fornecem
exemplos textuais dos interesses transversais no nível da Arquitetura Empresarial, mas
não indicam uma forma de representá-los ou explicitá-los.
4. Contribuição esperada e Avaliação dos resultados
As seguintes contribuições são esperadas deste trabalho: (i) identificação de uma lista de
características que são transversais às Arquiteturas Empresariais; (ii) identificação de
uma forma de representar interesses transversais no nível da Arquitetura Empresarial;
(iii) especificação de um método a ser utilizado por arquitetos para a identificação e
representação das características transversais;.
A validação desta solução se dará através de um estudo de caso, em uma
empresa real, onde poderá ser verificado se a forma de representação e o método
especificado são adequados para resolver o problema apresentado, bem como validar a
lista de possíveis interesses transversais. Além disso, será analisada a opinião de
especialistas com relação à relevância da identificação e representação dos interesses
transversais.
Referências
Bezerra, E. (2003). Princípios de análise e projeto de sistema com UML. Rio de Janeiro,
Elsevier.
Botto, R. Arquitetura Corporativa de Tecnologia da Informação. (2004). Rio de Janeiro,
Brasport.
425
VII Simpósio Brasileiro de Sistemas de Informação
Cappelli, C., Santoro, F., Leite, J., Batista, T. (2010a). O Conceito de Aspectos em
Sistemas de Informação. International Conference on Research and Practical Issues
of Enterprise Information Systems (CONFENIS), Natal, RN, Brasil.
Cappelli, C., Santoro, F., Leite, J., Batista, T., Medeiros, A., Romeiro, C. (2010b).
Reflections on the Modularity of Business Process Models: the Case for Introducing
the Aspect-Oriented Paradigm. BPM Journal.
Charfi, A. (2007). Aspect-Oriented Workow Languages: AO4BPEL and Applications,
Dr.-Ing. Thesis, der Technischen Universit at Darmstadt, Germain.
Elrad, T., Aksit, M., Kiczales, G., Lieberherr, K., Ossher, H. (2001). Discussing aspects
of AOP. Communications of ACM, vol. 44, ed. 10, pp. 33-38.
Filman, R., Elrad, T., Clarke, S., Aksit, M. (2005). Aspect-Oriented Software
Development. Addison-Wesley.
Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J., e Irwin, J.
(1997). Aspect-oriented programming. In Proceedings of the 11th European
Conference on Object-Oriented Programming. Springer-Verlag.
Medeiros, A. (2008). MARISA-MDD: Uma Abordagem para Transformações entre
Modelos Orientados a Aspectos: dos Requisitos ao Projeto Detalhado. Dissertação de
Mestrado em Sistemas e Computação – UFRN.
Park, C., Choi, H-J., Lee, D., Kang, S., Cho, H-K., Sohn, J-C. (2007). KnowledgeBased AOP Framework for Business Rule Aspects in Business Process. ETRI
Journal, vol. 29, n.4, pp. 477-488.
Rashid, A., Moreira, A., Araújo, J. (2003). Modularization and composition of Aspectual
Requirements. International Conference on Aspect-Oriented Software Development
(AOSD 2003), Boston, USA, March 17-21.
Silva, L., Batista, T. (2006). Mapeando Características Transversais de Modelos de
Requisitos para Especificações Arquiteturais. . III Workshop Brasileiro de
Desenvolvimento de Software Orientado a Aspectos WASP´2006.
Tirelo, F., Bigonha, R., Bigonha, M., Valente, M. (2004). Desenvolvimento de Software
Orientado por Aspectos. XXIII JAI – Jornada de Atualização em Informática.
Yu, Y., Leite, J., Mylopolous, J. (2004). From goals to aspects: discovering aspects from
requirements goal models. In: Proc. of IEEE Int. Symp. on Requirements Engineering
(RE'04), Japan, pp. 38-47.
Zachman, J. (1987). A Framework for Information Systems Architecture. IBM Systems
Journal, Vol 26, No 3.
426