... : : Arquitetura de TI, BPM , ontologias e tudo mais que temos direito.

Mudança de Domínio

2009-09-14T05:03:00.000-07:00

Galera,

Agora o blog mudou de domínio. O novo endereço será Enterprise Analysis

O Novo blog possui o mesmo objetivo deste. Ou seja, discutir sobre Arquitetura de TI, Ontologias, MDD e tudo mais que temos direito =)

Espero que o novo blog seja do agrado de vocês.

Abraços

E vamo que vamo ..

Desenvolvimento Orientado a Modelos ( Model-Driven Development)

2009-07-12T07:28:00.000-07:00

Atualmente existe uma grande distância entre a etapa de elicitação de requisitos e o desenvolvimento (codificação) de sistemas computacional (ALMEIDA, 2006), tornando, assim, o desenvolvimento de um aplicativo computacional demorado e custoso. O Desenvolvimento Orientado a Modelos é uma das possíveis soluções para aumentar a velocidade e diminuir o custo do desenvolvimento de um aplicativo computacional.

O Desenvolvimento Orientado a Modelos é uma abordagem de desenvolvimento de sistemas computacionais, que aumenta o poder da utilização de modelos (OMG, 2003) para esta finalidade. Esta abordagem proporciona um meio de utilizar modelos no curso do entendimento, projeto, construção, implantação, operação, manutenção e modificação de sistemas computacionais (OMG, 2003). Os modelos são expressos em linguagens de modelagem que possuem sua sintaxe abstrata descritas em modelos conhecidos como metamodelos (ALMEIDA et al., 2006b).

O Processo de Desenvolvimento Orientado a Modelos é caracterizado como uma seqüência de etapas de projeto que possuem como finalidade o desenvolvimento de um sistema computacional. Para cada etapa de projeto, atividades de projeto são executadas. Cada atividade de projeto contém uma atividade de transformação (do inglês, transformation activity) e uma atividade de avaliação (do inglês, assessment activities)(ALMEIDA et al., 2006a).

Uma atividade de transformação é uma atividade de projeto genérica que é responsável por produzir um modelo destino (do inglês, target model) tendo com base um modelo origem (do inglês, source design) e um ou mais requisito que devem ser satisfeitos. Uma atividade de avaliação é uma atividade de projeto genérica que possui como compromisso avaliar o modelo destino produzido pela atividade de transformação. A noção de modelo de origem e destino depende da etapa do projeto (ALMEIDA et al., 2006b). Em princípio, as atividades de avaliação devem incluir avaliação de conformidade (do inglês, conformance assessment) para avaliar se o modelo destino está em conformidade com o modelo de origem (ALMEIDA, 2006).

Durante o processo de desenvolvimento do sistema computacional, as atividades de transformações incorporam diversas decisões de projetos que adicionam características que eventualmente estarão associadas ao sistema em realização. Diferentes decisões de projeto guiam para diferentes alternativas de realização. A redução do espaço de realização imposta pelas sucessivas decisões de projeto é apresentada na figura abaixo.

Redução do espaço de soluções para um projeto com diferente níveis de abstração (ALMEIDA et al., 2006a).

As decisões de projeto realizadas em cada etapa do projeto devem reunir dois requisitos para que o processo de construção do sistema computacional tenha sucesso: (i) as decisões de projeto devem contribuir para satisfazer requisitos do sistema que ainda não foram compridos, e (ii) as decisões de projeto devem preservar as características que estão presentes modelo de origem, isto é, o modelo de destino deve estar em conformidade com o modelo de origem (ALMEIDA et al., 2006a).

Por fim, as decisões de projeto devem eventualmente guiam o projeto de desenvolvimento do sistema computacional, afim de, definir todas as características que são necessárias para o sistema em realização. A plataforma em que o sistema computacional irá ser desenvolvido, particularmente, define como as decisões de projeto podem ser feitas. De forma similar, as decisões de projeto definem as possíveis plataformas em que a o projeto pode ser realizado (ALMEIDA et al., 2006a).

Referências

ALMEIDA, J. P. A. Model-Driven Design of Distributed Applications, Ph.D. Thesis in Computer Science, CTIT Ph.D.-Thesis Series, No. 06-85, Telematica Instituut Fundamental Research Series, No. 018 (TI/FRS/018), Enschede, The Netherlands, 2006, ISBN 90-75176-422
ALMEIDA, J.P.A.; DIJKMAN, R.; SINDEREN, M.V,; QUARTEL, D.; PIRES, L. F. Model Driven Design, Refinement and Transformation of Abstract Interactions, International Journal of Cooperative Information Systems (IJCIS), Vol. 15, No. 4, 2006b, pp. 599-632.
ALMEIDA, J.P.A.; VAN ECK. P.; IACOB, M. E. Requirements Traceability and Transformation Conformance in Model-Driven Development, Tenth IEEE International EDOC Conference (EDOC 2006), IEEE Computer Society Press, 2006a, pp. 355-366.

ArchiMate

2009-06-28T12:59:00.000-07:00

O ArchiMate foi de desenvolvido por um consórcio composto dos seguintes membros: Telematica Instituut, Ordina, Radboud University Nijmegen, o Leiden Institute for Advanced Computer Science (LIACS) e o Centre for Mathematics and Computer Science (CWI) (ARCHIMATE, 2009).

A característica central da arquitetura é a orientação a serviços. Segundo (LANKHORST et al.,2005), serviços são “uma unidade de funcionalidade que alguma entidade disponibiliza para seu ambiente, e que possui algum valor para certas entidades do ambiente (tipicamente os “usuários dos serviços”)”.

A orientação a serviços, proposta no ArchiMate, permite uma visão em camadas dos modelos arquiteturais, onde o conceito de serviço é responsável pela ligação entre as diversas camadas da arquitetura. As camadas de serviços cujos serviços são disponibilizados às camadas superiores, são intercaladas com as camadas de implementação que executam os serviços. Em cada camada, também podem existir serviços internos.

De acordo com (LANKHORST et al.,2005), no ArchiMate as principais camadas (níveis de abstração) podem ser distinguidas em:

Camada de Negócio (Business Layer) responsável por oferecer produtos e serviços que são realizados pelos processos de negócios da organização;
Camada de Aplicação (Application Layer) da suporte a camada de negócio,oferecendo aplicativos; e
Camada de Tecnologia (Technology Layer) que oferece a infra-estrutura necessária para que os aplicativos funcionem (por exemplo, computadores e dispositivos de comunicação).

Cada uma dessas três camadas podem ser divididas em sub-camadas. Porém, o nível de abstração deve ser escolhido dependendo do objetivo modelado e das preocupações do stakeholders.

Para cada nível de abstração, a linguagem é estruturada em três dimensões de modelagem: estrutural/comportamental, interna/externa e individual/coletiva.

Na dimensão estrutural/comportamental, existe o aspecto estático (estrutural) e aspecto dinâmico (comportamental). Em cada camada existem os conceitos classificados como estáticos (estruturais) e dinâmicos (comportamentais). Os conceitos comportamentais são atribuídos aos conceitos estruturais de maneira a mostrar “quem” e “o que” exibe o comportamento. Os conceitos estruturais, por sua vez, são divididos em ativos (conceitos que realmente desempenham um comportamento) e passivos (conceitos que são objetos de algum comportamento desempenhado por outra entidade). Por exemplo, na camada de negócios, papéis, interfaces e colaboração (conceitos estruturais) são atribuídos a processos de negócios, serviços organizacionais e interações empresariais (conceitos comportamentais), respectivamente.

Por fim, com relação ao segundo aspecto, existe uma distinção entre visão externa (extern view) e visão interna (internal view) no sistema. Os serviços são acessados por interfaces que constituem a visão externa de um conceito estrutural.

Referências

LANKHORST, M. Enterprise Architecture at Work - Modelling, Communication and Analysis, Springer, 2005.
ARCHIMATE -Archimate Consortium, Archimate Resource Tree, disponível em:. Acesso em: 20 de Janeiro, 2009.

ARIS (Architecture for integrated Information Systems)

2009-06-22T13:29:00.000-07:00

O ARIS (ARchitecture for integrated Information Systems) é uma Framework de Arquitetura Organizacional de TI, que foi desenvolvido na universidade de Saarbrucken, Alemanha, em 1992 com o objetivo principal de permitir a descrição e desenvolvimento de sistemas de informação que estivessem integrados à estrutura da organização através de seus processos de negócio (ARIS, 1999). Através do ARIS é possível:

documentar os processos de negócios existentes na organização;
obter uma visão geral da organização para análise e projeto dos processos de negócios; e
apoiar o projeto de sistemas de informação (LANKHORST et al., 2005).

Este framework propõe uma arquitetura de modelagem de organizações chamada de ARIS Method, estruturada em cinco diferentes visões (organizacional, dados, controle, função e saída) e três diferentes camadas de abstração (requisitos, projeto e implementação) (ARIS, 1999). Dado o escopo dos modelos suportados pelo ARIS Method, esta abordagem pode ser considerada uma técnica abrangente de modelagem de organizações e de arquiteturas de TI (LANKHORST et al., 2005).

A visão organizacional descreve a hierarquia organizacional, isto é, descreve a comunicação e o relacionamento entre as unidades organizacionais de uma organização, revelando também os papéis dos indivíduos na organização (ARIS, 1999).

A visão de dados descreve as informações que são manipuladas na organização. Nesta visão é possível expressar como o conhecimento organizacional esta organizada e armazenada (ARIS, 2001).

A visão de função é utilizada para descrever as tarefas realizadas pela organização. Através dessa visão é possível expressar os objetivos organizacionais de cada tarefa realizada na organização e quais sistemas computacionais auxiliam em cada tarefa organizacional. Também é possível descrever a hierarquia das tarefas organizacionais.

A visão de controle descreve os processos de transformação da informação por meio de uma função ou um conjunto de funções. Como as funções representam atividades organizacionais potencialmente complexas, esta visão é usada para modelar processos de negócio na abordagem ARIS (ARIS, 1999). Através dessa visão é possível demonstrar o relacionamento entre os processos de negócio da organização e as demais entidades da organização (entidades organizacionais, recursos, informações e entre outros aspectos).

Em relação aos níveis de abstração propostos pelo ARIS, o Nível de Requisitos é destinado a atividades de modelagem do domínio do problema, ou seja, na elicitação de conceitos e detalhes referentes ao negócio e à organização, assim como o fechamento do escopo da modelagem abarcada pelos modelos e os objetivos pelos quais se justifica a modelagem. Assim, nesse momento, a perspectiva analisada deve ser inteiramente orientada à percepção que o usuário possui do negócio, bem como sua documentação e padrões (CARDOSO, 2007). Estão presentes neste primeiro nível os modelos de cadeia de eventos orientados a processos (eEPCs), diagrama de objetivos, dentre outros modelos que ajudam na modelagem do domínio do problema (CARDOSO, 2007).

O segundo nível de abstração, o nível de Especificação de Projeto, tem por objetivo construir modelos que retratem os conceitos de TI, ou seja, construir modelos que descrevam o projeto conceitual de arquitetura, requisitos funcionais de uma aplicação e infra-estrutura de um sistema, sem se ater, no entanto, a detalhes específicos a uma tecnologia (CARDOSO, 2007). Portanto, como esse nível implementa certas características do nível de Nível de Requisitos, é possível alterar-se alguns detalhes de especificação de projeto que implementem os mesmos conceitos do negócio, sem que, no entanto, seja necessário retornar ao Nível de Requisitos para atualizá-lo, o que garante flexibilidade no processo (CARDOSO, 2007).

O Nível de Descrição de Implementação, tem por objetivo traduzir a arquitetura descrita no Nível de Especificação de Projeto para modelos que descrevam detalhes tecnológicos dos componentes que irão implementá-la (CARDOSO, 2007). O Nível de Descrição de Implementação está intimamente ligado à tecnologia da informação e sua especificação pode ser apoiada pelos detalhes levantados no Nível de Especificação de Projeto (CARDOSO, 2007).

Cada uma das visões do ARIS Method possui uma linguagem própria, que pode ser definida através de sua sintaxe e semântica. A sintaxe concentra-se puramente nos aspectos notacionais de uma linguagem, ignorando completamente os significados dos elementos sintáticos, que são revelados apenas através da semântica de uma linguagem (HAREL et al., 2000). A definição semântica para uma linguagem L, ou simplesmente a semântica, é composta de duas partes: um domínio semântico e um mapeamento semântico dos elementos da sintaxe para o domínio semântico (HAREL et al., 2000).

Tendo como base o ARIS Method, diversas ferramentas foram desenvolvidas, como por exemplo, ARIS SOA Architect, ARIS Business Architect e ARIS Toolset. Estas ferramentas provêem um ambiente para modelagem, gerenciamento dos modelos produzidos e outros serviços de gerenciamento de processos (KERN et al., 2007). Em particular, neste trabalho, estamos interessados no ARIS Method e seu suporte através do ARIS Toolset. O interesse nesta ferramenta deve-se à grande importância industrial desta ferramenta na prática de modelagem de processos de negócio e arquiteturas de TI.

Conforme apresentado em (LANKHORST et al., 2007) (JONKERS et al., 2004), o alinhamento entre a tecnologia da informação e negócios da organização é reconhecido como uma boa pratica e de grande eficiência. A eficácia organizacional é obtida pela boa orquestração das relações entre os componentes organizacionais e não pela especificação detalhada de cada componente individualmente. O ARIS possibilita essa eficácia organizacional através das suas visões e suas camadas de abstração.

Por fim, utilização do ARIS no desenvolvimento de arquiteturas de TI (sistemas computacionais) é particularmente útil, isto ocorre, porque os modelos contidos no ARIS Method fornecem informações da estrutura organizacional, dos processos de negócios da organização e sistemas coorporativos que interagem com os processos de negócio e com a estrutura da organização. Desta forma, os modelos contidos no ARIS Method são de grande valia para o desenvolvimento de sistemas coorporativos que visão integrar todos os domínios do conhecimento da organização.

Referências:

ARIS - SCHEER, A.W., ARIS – Business Process Modeling, Third Edition, Springer, 1999.

JONKERS, H.; LANKHORST, M.; VAN BUUREN, R.S.; HOPPENBROUWERS, M.M. B; VAN DER TORRE, L. Concepts for modeling enterprise architectures. In special issue on Architecture in IT of the International Journal of Cooperative Information Systems, 13(3):257--287. World Scientific, Setembro 2004.
KERN, H.; KÜHNE, S. Model Interchange between ARIS and Eclipse EMF. The 7th OOPSLA Workshop Domain-Specific Modeling, 2007.
LANKHORST, M. Enterprise Architecture at Work - Modelling, Communication and Analysis, Springer, 2005.