Não está bom como eu queria, mas como o tempo urge, lá vai a segunda parte do Capítulo 3, que trata dos modelos existentes em uma MBIDE (ou MBUIDE, como diria (PINHEIRO, 2oo1)).
Os Tipos de Modelos
Como elementos centrais nas ferramentas MBIDEs estão seus modelos de armazenamento e configuração, os quais variam em conteúdo e objetivos. Análises diversas (PINHEIRO, 2001), (SZEKELY, 1996) e (SCHULUNGBAUM, 1996) afirmam que as MBIDEs podem ser classificadas cronológica e arquiteturalmente conforme o conjunto de modelos suportados.
De fato, é a partir dos modelos que as ferramentas definem suas formas de trabalho e, consequentemente, o processo de software a ser aplicado quando da sua utilização (BODART, LEHEUREUX e VANDERDONCKT, 1994). Partindo dessa afirmativa, uma análise sobre esses artefatos é de grande importância para esse trabalho. Assim, as próximas seções descrevem, em alto nível, os nove tipos de modelos consensualmente aceitos na área das ferramentas de geração baseada em modelos.
A) Modelo de Dados
Modelos de Dados é a base para geração de interfaces CRUD, pois tem um mapeamento quase direto entre um elemento de dado (um atributo em uma tabela, por exemplo) e um controle de tela (uma caixa de texto, por exemplo) e são bastante utilizados pelas ferramentas MBIDEs de primeira geração (SZEKELY, 1996).
Sob uma ótica simples, esse modelo pode ser interpretado como um subconjuto do Modelo de Domínio, e pode ser comparado a um típico modelo Entidade-Relacionamento, pois dentro dele estão contidas todas informações sobre os dados que podem ser manipulados pelo sistema.
Obrigatoriedade, valores-padrão, intervalos mínimos e máximos, tipo de dado e outras informações tipicamente presentes nesse modelo são utilizadas pela grande maioria das MBIDEs para produzir, com a ajuda de algumas heurísticas e algoritmos simplistas, as interfaces responsáveis pela visualização e edição da estrutura de dados relacionada (PUERTA et al., 1996).
FIGURA DE UM DIAGRAMA UML COM 3 CLASSES RELACIONADAS E UMA IU CRUD RUDIMENTAR GERADA EM FUNCAO DELE
Observa-se na Figura 3.1 que os descritivos dos controles foram produzidos a partir do próprio nome do atributo da classe, e que os tipos dos controles foram definidos em função do tipo de dado do atributo.
Como regra geral, as MBIDEs mapeiam uma tabela ou classe para uma ou várias interfaces CRUD, sendo que cada atributo (da classe ou tabela) é mapeado para um controle de tela (PINHEIRO, 2001) (MRACK e MOREIRA, 2003).
B) Modelo de Domínio
O Modelo de Domínio é o elemento central das ferramentas MBIDEs, servindo como base para geração da IU. A partir dele são extraídas várias informações que, através de heurísticas e algoritmos diversos, podem ser derivadas nos elementos que compõem os formulários da aplicação.
Este modelo excede o Modelo de Dados por conter também as informações comportamentais do sistema. De certa forma, ele pode ser interpretado como um Diagrama de Classes da UML, suportando diversos tipos de relacionamentos entre as estruturas (como herança, agregação, composição), bem como tipos de dados definidos pelo usuário e também conceitos de mais alto nível, como classes abstratas, finais, interfaces e enumerações (OMG).
Porém, o que mais distingue esse modelo do Modelo de Dados é a presença de operações, ou métodos de classes. Dessa forma, um Modelo de Domínio pode representar não somente a estrutura de uma IU, mas também o seu comportamento. Projetos como o MECANO (PUERTA et al., 1996), MERLIN (MRACK, 2005) são apenas alguns exemplos de soluções que centralizam todo o desenvolvimento do sistema sobre esse modelo.
Conforme a análise de (PINHEIRO, 2001) e (SZEKELY, 1996), os Modelos de Domínio vieram para substituir os Modelos de Dados e são vistos como elementos essenciais nas MBIDEs mais atuais.
C) Modelo de Tarefa
Este modelo pode ser interpretado como uma grande árvore composta de tarefas e sub-tarefas, onde cada uma representa uma atividade que o usuário pode executar no sistema. Como não existe um padrão para descrever esses modelos, cada ferramenta que adota-o, o faz com base em um estilo próprio .
Entre as informações contidas nesse modelo, estão a ordem de execução das tarefas, as pré e pós-condições, questões sobre paralelismo, dependências, obrigatoriedade e outras (GRAY et al., 1998). No tocante à vinculação dessas tarefas aos elementos de tela, algumas soluções fazem-o diretamente nesse modelo, outras optam por fazer isso no Modelo de Diálogo.
Muitas dúvidas pairam sobre esse modelo, uma vez que, dependendo da ferramenta, as tarefas podem ser interpretadas de forma abstrata, concreta (métodos em uma classe, por exemplo) ou mesmo com o uso de formalismos (BARON e GIRARD, 2002). Uma das MBIDEs que mais coloca ênfase sobre esse modelo é a TRIDENT (BODART, LEHEUREUX e VANDERDONCKT, 1994), tomando-o como ponto de referência não só para a definição dos outros modelos do sistema, mas também para a modelagem de toda a aplicação.
A Figura 3.2 mostra a representação gráfica de um modelo de tarefas derivado do projeto TRIDENT, no qual as tarefas são descritas através de um modelo formal (SOUCHON, LIMBOURG e VANDERDONCK, 2002)
FIGURA COM UMA ARVORE DE TAREFAS, NA QUAL CADA VÉRTICE É UMA TAREFA ESPECIFICADA EM ALTO NIVEL, E CADA ARESTA É UMA DEPENDENCIA, AS QUAIS POSSUEM ORDENAMENTO, CONDICOES DE NAVEGACAO, OPERACAO PARALELA, EXCECOES, ETC.
Figura 3.2: Visualização gráfica de um modelo de tarefas derivado do projeto TRIDENT (SOUCHON, LIMBOURG e VANDERDONCK, 2002).
D) Modelo de Usuário
Este modelo não tem uma descrição ou comportamento exatos. De fato, muitas ferramentas simplesmente o ignoram, e a abordagem utilizada por elas para satisfazer esse componente é dispersar suas características em outros modelos.
Na prática, o objetivo desse componente é armazenar informações características de um usuário ou perfil específico da aplicação em relação às configurações gerais da ferramenta. Em outras palavras, é nesse modelo que devem ficar armazenados comportamentos e especializações de tela, como teclas de atalho personalizadas, valores-padrão para controles de tela baseados em perfil do usuário, informações referentes à controle de acesso e outras (SCHLUNGBAUM, 1997).
A maioria das ferramentas existentes não explicita em detalhes o funcionamento desse elemento, mas, de modo geral, são capazes de satisfazê-lo em determinado nível à sua maneira (PINHEIRO, 2001).
E) Modelo de Diálogo
Também conhecido como Modelo de Conversação (RRR), define como os objetos da IU devem interagir com o usuário. Ele representa as ações que o usuário pode invocar através dos elementos da camada de apresentação e as respostas que a aplicação deve produzir através desses mesmos elementos.
De forma geral, ele está muito ligado ao Modelo de Apresentação e ao Modelo de Tarefas, sendo que, muitas vezes, confunde-se com esses. Essa afirmativa pode ser tanto apreciada em (PINHEIRO, 2001), que simplesmente une-os em seu ensaio comparativo de ferramentas da área, como em (SCHULUNGBAUM, 1996), que descreve o aparecimento desse modelo como sendo uma evolução arquitetural das modernas MBIDEs.
F) Modelo de Apresentação
Após o Modelo de Domínio, o Modelo de Apresentação pode ser considerado o segundo modelo mais importante em uma ferramenta MBIDE. É nele que ficam armazenadas as informações referentes à aparência da tela (PUERTA e EISENSTEIN, 1999). Características dos elementos de tela como layout de controles, posicionamento, tamanho, regras para redimensionamento, esquema de cores, ordem de tabulação e outras são centralizadas nesse componente.
Devido à sua acentuada dependência em relação ao toolkit gráfico utilizado pelo sistema, as ferramentas MBIDE encontram nesse item um separador de águas em relação à sua arquitetura interna. Isso ocorre porque elas precisam considerar duas abordagens diferentes para estruturar esse modelo:
· Abstract Interface Objects (AIO): Ferramentas que utilizam informações abstratas para descrever o modelo de apresentação simplesmente ignoram o toolkit gráfico para configuração desse componente. Assim, é eleito um conjunto de configurações que podem estar presentes nos toolktis gráficos suportados pelo gerador de forma que, em um segundo instante, na geração da IU, as informações abstratas são mapeadas pelo gerador para o toolkit gráfico escolhido. Na eventualidade de uma informação existente no AIO não estar presente no toolkit gráfico escolhido, uma perda de qualidade no resultado é esperada (BODART, LEHEUREUX e VANDERDONCKT, 1994).
· Concrete Interface Objects (CIO): Soluções que usam essa abordagem definem o modelo de apresentação utilizando as primitivas do próprio toolkit gráfico a ser utilizado na geração da IU.
É interessante notar que alguns trabalhos advogam que é possível operar ambos os modelos ao mesmo tempo, de forma que, em um processo evolutivo, AIOs são paulatinamente transformados em CIOs. A justificativa para issso é que somente através dos CIOs é possível especificar os detalhes necessários para a geração de uma IU mais elaborada. Na Figura 3.3 pode ser vista uma comparação entre AIOs e CIOs em duas ferramentas MBIDEs:
FIGURA COMPARATIVA, MOSTRANDO AIOS NA FERRAMENTA TRIDENT E AIOS E CIOS NO MERLIN (PRA TER UMA IDEIA, IMAGINE UM CODIGO JAVA COM ANOTACOES - EH EXATAMENTE ISSO QUE O MERLIN USA PARA DEFINIR SEUS AIOS E CIOS)
Figura 3.3 : Fragmentos de modelos de apresentação nas ferramentas TRIDENT (BODART, LEHEUREUX e VANDERDONCKT, 1994) e MERLIN (MRACK, 2007).
Nessa figura, observa-se que um AIO não especifica nenhum detalhe relevante para o toolkit gráfico – é tarefa do gerador interpretar essas informações e traduzí-las no CIO correspondente. Na parte direita da figura, AIOs e CIOs estão misturados entre si sobre o próprio Modelo de Domínio.
De importante interesse, porém, pode ser a abordagem oferecida pela ferramenta MOBI-D (PUERTA e EISENSTEIN, 1999), a qual explicita um mecanismo configurável e relativamente avançado para mapeamento entre AIOs e CIOs. Tal ênfase é tão grande, que os autores sugerem um novo tipo de modelo, o chamado Modelo de Projeto. Entretanto, uma vez que somente este trabalho referencia tal componente, ele não é considerado um elemento ao mesmo nível dos outros modelos existentes.
G) Modelo de Aplicação
Este modelo pode ser interpretado como o superconjunto do Modelo de Domínio, pois contém informações que vão além daquelas existentes naquele componente. De forma geral, um Modelo de Aplicação descreve as características mais gerais do sistema, e não simplesmente aquelas referentes ao problema a ser tratado.
São exemplos de informações contidas nesse modelo as classes auxiliares de suporte à aplicação, dados de configuração do sistema e parâmetros como conexões à banco de dados, serviços remotos e outros.
Quanto à formação, detalhamento e fronteiras desse componente, os trabalhos não explícitos, sendo que muitos simplesmente ignoram-o (PINHEIRO, 2001).
H) Modelo de Plataforma
Da mesma forma que o Modelo de Aplicação, não existe um consenso sobre esse modelo. Algumas ferramentas simplesmente descartam-no (PUERTA et al., 1996) e outras fundem-no com o Modelo de Aplicação (LUYTEN, 2004) sem maiores preciosismos.
O objetivo desse modelo é descrever os detalhamentos necessários da aplicação perante o ambiente em que ela está sendo executada. Informações como o toolkit gráfico e o banco de dados a ser utilizado pelo sistema são descritos nesse componente. Embora ele seja de suma importância para a completude de uma MBIDE, a existência explícita desse componente não é justificável, uma vez que cada ferramenta pode escolher a melhor forma de implementá-lo sem demasiados prejuízos para o cenário de desenvolvimento.
I) Modelo de Contexto
De forma geral, esse artefato não é considerado um modelo no sentido exato da palavra pois, com exceção à (LUYTEN, 2004), nenhum dos trabalhos estudados faz menção explícita a esse tipo de componente.
Um Modelo de Contexto descreve os aspectos de uma aplicação que não podem ser conhecidos durante sua construção, pois dependem da interação do usuário para sua formação. Entre as informações que podem ser residir nesse modelo estão dados comportamentais do usuário, como preferências na execução de comandos (se por teclas de atalho ou chamadas de menus, por exemplo), ordem de preenchimento de campos na tela, utilização ou não de valores-padrão existentes nos controles da IU e outros.
Grosso modo, esse é um modelo que somente pode ser obtido ao longo do uso do sistema, não sendo possível sua concepção durante a fase de projeto da aplicação. Em certos aspectos pode se confundir com o Modelo de Usuário, embora se diferencie desse por ser algo mais dinâmico.
