Análise de domínio
 | Este artigo ou secção contém uma lista de referências no fim do texto, mas as suas fontes não são claras porque não são citadas no corpo do artigo, o que compromete a confiabilidade das informações. (Outubro de 2016) |
O termo domínio, no contexto da engenharia de software, é utilizado para denotar ou agrupar um conjunto de sistemas ou de áreas funcionais, dentro dos sistemas, que exibem funcionalidades similares. Podemos então descrever o domínio aplicacional, como sendo uma coleção de aplicações de software, que partilham um determinado conjunto de características. Da mesma forma, o domínio é definido por um conjunto de características que descrevem uma família de problemas para os quais uma determinada aplicação pretende dar solução.
A análise do domínio pode ser definida como o processo pelo qual a informação usada para o desenvolvimento de software é identificada, capturada e organizada para que seja reutilizável quando da criação de novos sistemas. Trata-se da reutilização de conceitos a um nível de abstração muito elevado, ou seja, existem soluções generalistas para a resolução de um dado problema, que podem ser aplicadas em contextos similares. A identificação dos domínios não se restringe às áreas técnicas e tecnológicas. Elementos socio-econômicos, organizacionais, administrativos, etc. têm influência para determinar o âmbito do problema, pelo que é imperativo a sua investigação e análise.
Engenharia de domínio e análise de domínio
[editar | editar código-fonte]Apesar de normalmente se empregar os dois termos de forma indiscriminada e inconsistente, estes são diferenciados e devem ser empregues em contextos diferentes. A análise do domínio é um processo que faz parte do âmbito da engenharia de domínio, mas que pode ser utilizada de forma independente. A engenharia de domínio abrange as seguintes áreas:
- Definição do âmbito (definição do domínio)
- Análise do domínio
- Desenvolvimento da arquitectura do domínio
- Construção dos componentes (requisitos, designs, código, documentação)
Esta tem como objectivo a reutilização, num sentido mais lato, de componentes numa classe de sistemas.
Relativamente à engenharia de sistemas, que visa a implementações de solução perfeitamente definidas e únicas, a engenharia de domínio é muito mais abrangente, pois visa proporcionar uma solução cujas funcionalidades possam ser reutilizadas em múltiplos sistemas.
Métodos de análise de domínio
[editar | editar código-fonte]Existem diversos métodos de análise de domínio, sendo estes aplicados em vários níveis conceituais mas, é pressuposto que qualquer um deles possa ser definido pelos seguintes elementos:
- Uma ontologia de domínio, assim como a taxionomia desta ontologia, aparecendo estas no modelo de domínio.
- Um processo a ser seguido para a construção do modelo de domínio.
O modelo do domínio representa a compreensão e informação adquirida acerca do domínio. O processo de obtenção deste modelo segue os seguintes passos:
- Caracterização do domínio e planejamento do projeto: fase de análise e planejamento.
- Levantamento de dados. As fontes de levantamento de informação são diversas e podem abranger a análise de documentação, consulta a especialistas, etc.
- Análise de dados. O propósito desta fase é construir descrições de componentes reutilizáveis, identificando similaridades e diferenças entre eles.
- Classificação. A informação modelada no passo anterior é refinada, agrupada e hierarquizada.
- Avaliação do modelo de domínio. Esta atividade visa avaliar o modelo obtido, sendo aqui efetuadas as correções necessárias.
Classificação dos métodos de análise
[editar | editar código-fonte]Os métodos de análise de domínio dependem e são aplicados conforme o tipo de objeto a ser reutilizado e o âmbito do problema a ser resolvido. Sendo assim, a classificação dos métodos está dependente do tipo de elementos que se pretende reutilizar:
- Produtos de software.
- Processos de software.
- Tecnologia de software.
- Experiência de software.
Relativamente à análise de produtos de software, esta incide sobre a reutilização de código, arquitetura e requisitos. Pode ser orientada para o levantamento de componentes de software, que providenciem as funcionalidades necessárias a quem implementa, ou seja, analisa-se o código que pode ser reutilizado, nomeadamente a partir de bibliotecas, que implementem alguma das funcionalidades pretendidas e a ser integradas no produto a desenvolver. Também se pode orientar o processo de análise com o intuito de reutilizar arquiteturas ou designs. Neste caso, o arquiteto de software pode proceder a uma análise de domínio que o conduza ao levantamento de padrões de software e frameworks, que resolvem problemas comuns no âmbito do desenvolvimento orientado a objetos. Finalmente, pode-se proceder à reutilização na fase de análise do ciclo de desenvolvimento de software, isto é, para a reutilização de requisitos que poderão ser comuns a produtos com fins similares.
Pode-se também recorrer a métodos para reutilizar toda e qualquer experiência de desenvolvimento, que se aplique ao contexto do produto em questão, nomeadamente ao nível de metodologias de desenvolvimento. Como exemplo, poder-se-á estudar o domínio de metodologias aplicadas a um projeto de desenvolvimento de software, e com base na informação obtida de experiências anteriores, adaptar a que mais se adequa ao projeto em questão.
Lista de métodos de análise
[editar | editar código-fonte]A tabela seguinte apresenta um levantamento de métodos que podem ser utilizados para a análise do domínio. A primeira coluna corresponde à designação do método e a segunda aos objectivos propostos por este. A terceira coluna da tabela apresenta uma definição geral do método e a última coluna apresenta a classe a que este pertence (ver secção anterior), ou seja, qual o objeto de reutilização para o domínio.
| Métodos de análise | Objectivo | Definição | Classe |
|---|---|---|---|
| McCain | Diminuir custos de adaptação | Determinar características que optimizem o domínio | Produtos (código) |
| Neighboors | Melhorar elementos reutilizáveis | Identificar objectos e operações de uma classe de sistemas | Produtos (código) |
| Prieto-Díaz | Melhorar elementos reutilizáveis | Actividade que precede a análise do sistema | Produtos (código) |
| Simos | Construir bibliotecas com elementos reutilizáveis | Especificação do modelo do domínio para uma biblioteca | Produtos (código) |
| HP | Construir elementos reutilizáveis | Caracterizar o domínio de software | Produtos (código) |
| ODM | Construir elementos reutilizáveis | Produtos (código) | |
| FODA | Construir elementos reutilizáveis | Processo de identificar, organizar e representar informação relevante acerca do domínio | Produtos (arquitectura) |
| IDeA | Construir bibliotecas com elementos reutilizáveis | Produtos (arquitectura) | |
| STARS | Construir bibliotecas com elementos reutilizáveis | Análise de sistemas | Produtos (arquitectura) |
| DADO | Integrar a análise do domínio no processo de desenvolvimento | Processo para identificar e organizar informação acerca do utilizador | Produtos (arquitectura) |
| Synthesis | Diminuir custos de adaptação | Identificar, organizar e modelar informação para produzir requisitos | Produtos (requisitos) |
| JODA | Construir elementos reutilizáveis | Processo em que é definida uma arquitectura e código reutilizáveis | Produtos (requisitos) |
| Hollenbach & Frakes | Construir bibliotecas com elementos reutilizáveis | Processos | |
| Birk | Construir elementos reutilizáveis | Identificar e organizar conhecimento acerca de um tipo de problemas para os descrever e resolver | Tecnologia |
| Basili | Construir elementos reutilizáveis | Identificar domínios em que a reutilização de certas experiências é vantajosa | Experiência |
| Henninger | Construir bibliotecas com elementos reutilizáveis | Identificar padrões que se repetem no decorrer de projectos de desenvolvimento | Experiência |
Dificuldades na análise de domínio
[editar | editar código-fonte]O domínio pode tornar-se mais complexo e difícil de ser avaliado ou transcrito, consoante a área em que um determinado projecto esteja inserido. Actualmente, podem ser encontrados produtos de software com os mais diversos fins. Ao mesmo tempo o nível de exigência em relação à qualidade da prestação dos serviços destes, é cada vez maior pelo que, para se alcançar estes propósitos, é necessário ter a noção de todos os factores que possam ter impacto no produto pretendido. No entanto, quanto maior o número factores, mais complexo o processo se torna, e maior é o número de situações que devem ser tidas em conta.
As observações efectuadas na análise permitem um levantamento elucidativo de características, cuja transcrição para o papel pode ser difícil e complexa. No dia a dia confrontamo-nos com processos porventura simples, mas cujo “modus operandis” é difícil de demonstrar e de transcrever através de uma linguagem simples e elucidativa. Recorrendo a esquemas, diagramas e a uma linguagem eventualmente mais técnica deverá procurar-se encontrar um meio de tornar evidente, a quem está a tomar contacto com os artefactos resultantes da análise do domínio, de quais são as características que o compõem, qual o âmbito em que este se insere, que problemas lhe estão inerentes e que soluções existem.
As dificuldades surgem também quando estamos a efectuar uma análise num domínio instável, em que as soluções existentes são ambíguas e pouco claras. Tal acontece quando existem poucas fontes de informação disponíveis, ou então, quando estas não são adequadas para um levantamento de informação credível. Tal acontece, essencialmente quando um foco de um projecto está na implementação de produtos inovadores, em que não existem disponíveis referências que permitam definir um domínio contextualizante e com elementos reutilizáveis.
Análise de domínio no processo de levantamento de requisitos
[editar | editar código-fonte]O levantamento de requisitos está presente no início do ciclo de vida de software, numa fase em que os responsáveis pelo desenho do sistema estão a adquirir toda a informação necessária, para garantir que o produto em questão satisfaça quem o vai consumir. O levantamento é efectuado através do contacto com pessoas que se inserem no meio onde o projecto decorre, sendo empregues diversas técnicas (entrevistas, questionários, brainstormings, etc.).
Com a análise do domínio pretende-se indicar um meio, através do qual, se possa atingir a coerência entre a representação e abstracção de um modelo que guie a um levantamento de requisitos eficaz e profícuo. Quando se desenvolve um novo sistema, não é suficiente questionar as pessoas sobre o que é que estas pretendem obter. Existem muitos outros factores que devem ser do conhecimento das equipes de desenvolvimento, muito antes de serem tomadas quaisquer decisões relativas ao avanço na elaboração do projeto, nomeadamente relativamente ao domínio em que este se insere. Acontece normalmente que os próprios clientes do projeto, não têm uma noção abrangente e aprofundada do problema e das possíveis soluções que o produto pretendido abarca.
Sendo assim, esta análise é crucial quando se pretende determinar quais os parâmetros que definem o caminho que uma eventual solução deve seguir, ao mesmo tempo que vai condicionar algumas das opções que poderiam ser consideradas como viáveis e ajustadas para a implementação final. Tem como objectivo aprofundar e detalhar o conhecimento que os responsáveis pelo desenvolvimento têm sobre a área em que o produto se insere, para que possam ter uma linha condutora para as diversas etapas do processo de levantamento de requisitos.
A análise de domínio permite levantar tecnologias, componentes, metodologias e outras informações acerca do domínio em que se insere o produto a desenvolver. Esta análise, feita antecipadamente relativamente e/ou paralelamente aquando do contacto com o(s) cliente(s), permite ter uma visão do que já existe e pode ser reutilizado, o que enriquece de forma ampla a condução do processos de levantamento de requisitos. Além disso, a análise permite identificar requisitos, que serviram como base para a implementação de soluções similares, mas que poderiam passar despercebidos durante o processo de levantamento.
Documentação
[editar | editar código-fonte]A transcrição que vai ser documentada, da especificação genérica do domínio, deverá ser efectuada recorrendo a uma linguagem simples e directa, utilizando-se eventualmente esquemas que possam elucidar a mensagem que se pretende transmitir, procurando assim sempre que a ideia a difundir seja o mais explícita possível.
A análise do domínio é incorporada no artefacto com a designação de documento de visão que, tal como o nome implica, tem como objectivo dar uma visão global do projecto, o que inclui o seu domínio, de forma a orientar o processo de levantamento de requisitos.
Referências
[editar | editar código-fonte]- R. Prieto-Diaz. Implementing faceted classification of software reuse. Communications of the ACM, May 1991
- Arango G., A brief introduction to domain analysis, ACM, 1994
- X. Ferré, S. Vegas. An evaluation of domains analysis methods