3 Apoio à Colaboração no Desenvolvimento Distribuído de Software
3.5 Um Modelo de Características para o Domínio de Aplicação
O desenvolvimento de software clássico, seguindo o ciclo de vida cascata, começa pela análise de requisitos do sistema e se estende para projeto, implementação e testes (PRESSMAN, 2002). Entretanto, com o passar do tempo, os engenheiros de software constataram que muitos sistemas compartilhavam semelhanças, e que o retrabalho do desenvolvimento de software poderia ser diminuído através da reutilização de especificações, modelos e código-fonte. A prática de reutilização de software implica um aumento da produtividade da equipe de desenvolvimento e da qualidade e confiabilidade do produto, além de contribuir para a diminuição dos custos.
Contudo, para que a reutilização seja possível, o desenvolvimento de software precisa passar por uma etapa anterior, onde são analisadas, projetadas e implementadas as características comuns em relação ao domínio em questão. Essa etapa chama-se engenharia de domínio.
Dessa forma, podemos definir dois pontos de vista para o desenvolvimento de software: o desenvolvimento para reuso e o desenvolvimento com reuso (MOORE e BAILIN, 1991). O desenvolvimento para reuso, ou Engenharia de Domínio, se preocupa com a geração de componentes reutilizáveis em um determinado domínio. O desenvolvimento com reuso, ou Engenharia da Aplicação, se preocupa em construir aplicações reutilizando os componentes criados na Engenharia de Domínio. A Engenharia da Aplicação serve também como agente motivador para a construção de
novos componentes inexistentes na base de componentes do domínio.
Para representar o domínio de apoio à percepção utilizando modelos de domínio, em um nível de abstração que facilite a aquisição de conhecimento, construímos inicialmente um modelo de características do domínio (BRAGA, 2001). O modelo de características tem como objetivo representar graficamente os conceitos e funcionalidades do domínio. O seu nível de abstração é alto, se preocupando em representar o conhecimento descrito nos casos de uso existentes no domínio.
Utilizamos a abordagem proposta pelo projeto Odyssey (WERNER et al., 2000), que usa extensões da UML para representar o conhecimento de um domínio, como, por exemplo, diagramas de contexto e de características (MILLER, 2001, OLIVEIRA et al., 2005).
O modelo de características apresentado é resultado de uma análise do domínio de ambientes de desenvolvimento colaborativos, limitado ao contexto de apoio à percepção, dentro desse domínio. A aquisição de conhecimento foi realizada por meio da literatura revisada neste capítulo. Os pontos de variação e as variantes são as características de maior interesse (GRISS et al., 1998). Cada ponto de variação indica um grupo de alternativas (variantes) que podem ser mutuamente exclusivas ou não.
A Figura 3.2 apresenta um modelo de características que modela os elementos em comum e a diversidade apresentada pelas ferramentas estudadas, usando a notação proposta por Oliveira et al. (2005).
Figura 3.2 Modelo de características para o domínio de ambientes globalizados de desenvolvimento
Legenda:
de software (Diagrama de características, notação Oliveira et al. (2005)).
O primeiro conceito fundamental se refere aos aspectos da colaboração (Collaboration Aspects) e o papel da percepção na colaboração. A colaboração pode ser decomposta em quatro aspectos: comunicação, coordenação, memória e percepção (respectivamente: Communication, Coordination, Memory e Awareness). Todos os autores concordam que a percepção é um aspecto importante, mas que seu efeito é de alguma forma influenciado por outros aspectos.
O segundo conceito fundamental trata dos atributos do objeto compartilhado considerados na percepção (Object Awareness Attributes). O objeto compartilhado varia de acordo com a tarefa a ser realizada. Existem quatro conjuntos de atributos para o objeto compartilhado: modelo, diagrama, WIMP e documento (respectivamente: Model,
Diagram, WIMP e Document). Os atributos do modelo são referências ao modelo da
UML: classificadores, características, modificadores etc. Os atributos do diagrama são referências à sintaxe concreta da UML: caixas, linhas, texto e a posição dos elementos no diagrama. Os atributos WIMP são referências para elementos da interface de usuário: janelas, menus, ponteiros, barras de rolagem etc. Por fim, os atributos do documento são referências para uma estrutura de documentos com pastas, arquivos, linhas, colunas, palavras e letras.
É possível que um mesmo objeto na área de trabalho esteja representado em todos os quatro conjuntos de atributos. Por exemplo, um modelo de classes da UML é descrito como: (a) um modelo, que é uma entidade abstrata, sem representação visual; (b) um diagrama de classes, que usa uma notação para apresentar o modelo; (c) um documento, que pode ser um programa em uma linguagem de programação ou alguma outra notação textual para o modelo e, finalmente, (d) o diagrama e o documento são apresentados em uma interface de usuário que permite criar, alterar e inspecionar cada elemento do modelo (visualizador).
Os atributos do modelo existem nas três outras representações, entretanto, os atributos das representações não são representáveis no modelo. Por exemplo, a definição de uma classe A pode ser observada tanto no diagrama, na interface de usuário e no documento, pois é um atributo do modelo. Por outro lado, um documento apresenta linhas e colunas que não são relevantes ao nível do modelo. Apesar disso, com o uso do modelo é possível identificar um mesmo elemento nas demais representações. Por
exemplo, a linha que define uma classe no documento pode ser relacionada com a mesma definição no diagrama e a sua apresentação em algum elemento da interface de usuário. Esta última propriedade permite que o usuário perceba o elemento do modelo em todas as representações.
Os atributos de percepção são explorados em dois modelos de percepção (Awareness Model). Primeiro, a relação causal entre as mudanças é usada para ordenar eventos e para agrupar mudanças relacionadas. Por exemplo, é necessário criar a classe antes de atribuir um método a ela. A criação do método e da classe, executadas em uma seqüência, pode indicar que os dois elementos fazem parte de uma mesma ação atômica do ponto de vista do usuário final. Segundo, a relação espacial entre elementos pode indicar um relacionamento semântico. Por exemplo, uma alteração em um método causa também uma alteração em sua classe, devido a relação entre os dois atributos.
A Tabela 3-3 resume a ocorrência das características citadas. As duas características restantes são: (a) a capacidade cognitiva (Cognitive Capabilities) e (b) os sentidos (Senses) propriedades do indivíduo. As ferramentas analisadas atuam como amplificadores da capacidade cognitiva ou dos sentidos do usuário. As capacidades cognitivas consideradas são: (a) a memória (Memory), responsável pelo armazenamento e recuperação de informações, e a (b) associatividade (Associativity), responsável pela conexão entre informações. As características cognitivas aparecem relacionadas com o trabalho assíncrono. Os sentidos considerados são: (a) a visão (Vision), responsável pela percepção da luz, ou seja, de imagens e movimento, e (b) a audição (Hearing), responsável pela percepção do som. As características dos sentidos aparecem relacionadas com o trabalho síncrono.
As características propostas podem ser utilizadas para comparar sistemas existentes de forma mais objetiva. Esta classificação ainda não é definitiva e exige trabalhos futuros. A medida que novos sistemas forem revisados, novas características podem ser propostas, ampliando a classificação.
Tabela 3-4 Características do modelo de domínio e a sua associação com as ferramentas.
Ferramentas Características
Palantír MILOS Serendipity Tukan Atributos do Objeto Compartilhado
Modelo ○ ○ ● ○
Diagrama ○ ○ ● ○
WIMP ○ ● ● ●
Documento ● ● ○ ●
Proximidade no Modelo de Percepção
Causal ○ ● ○ ● Espacial ● ○ ● ○ Cognição Memória ● ○ ○ ● Associação ● ○ ○ ● Sentidos Visão ● ● ● ● Audição ○ ● ○ ○
Legenda: ● presente ○ ausente