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
A engenharia de domínio abrange as
seguintes áreas:
Definição do âmbito (definição do domínio) e
Análise de viabilidade
Análise do domínio
Desenvolvimento da arquitetura do domínio Construção dos componentes (requisitos,
As duas últimas estão inseridas no projeto do
domínio.
Esta tem como objetivo a reutilização de
Consiste em levantar as estimativas de custo, de
projetar a família de aplicações e o retorno previsto ao longo do tempo.
Nesta atividade são realizados 4 passos
1. Estudar o mercado da aplicação em questão,
levando em conta potenciais clientes e concorrentes;
2. Caso o estudo do passo 1 mostre que há
potencial econômico, fazer um estudo do domínio, para se identificar comonalidades (pontos comuns) e variabilidades (pontos variáveis) de forma superficial;
3. Baseado nas informações do passo 2, fazer
uma análise do custo das atividades de reengenharia, engenharia de domínio e engenharia de componentes;e
4. Por fim, analisar o tempo de retorno de
investimento estimado e com base nesse tempo, dar o parecer de viabilidade.
Esta atividade consiste em entender os
conceitos gerais do domínio e deixá-los
registrados através de artefatos próprios que serão gerados.
Nesta atividade são realizados 9 passos
1. Para cada caso de uso identificar nomes
próprios (substantivos) centrais na
descrição do caso;
2. Elaborar uma lista de todos os nomes
próprios extraídos dos casos de uso;
3. Verificar a existência de sinônimos
(pessoa, usuário, colaborador). Acrescentar
ao glossário do domínio, associando um
sinônimo como termo principal e os outros
como termos secundários, além de produzir
uma pequena definição;
4. Verificar a existência de significados
aninhados (uma generalização ou
especialização), ex.: unidade de negócios,
gerência. Acrescentar ao modelo de features (como feature e sub-feature);
5. Acrescentar todos os nomes próprios
identificados ao glossário do domínio associando cada um a uma explicação;
6. Cada nome próprio vai corresponder a uma
7. Estender o modelo de features se necessários
através de brainstorm(idéias brilhantes) com
stakeholders para torná-lo mais genérico;
8. A partir do modelo de features e do relatório da
análise de viabilidade definir o modelo de classes do domínio com o objetivo de retratar apenas os
conceitos do domínio. A regra geral é mapear
features como classes, exceto features alternativas
que podem ser mapeadas como atributos ou classes de associações, esta questão poderá ser tratada
mais apropriadamente na atividade de Projeto do Domínio;e
9. Caso seja percebido alguma restrição ou
comportamento do domínio que possa ser modelado usando outro artefato como diagrama de seqüência ou de estados, recomenda-se gerar o artefato.
Nessa atividade, o engenheiro de domínio
confronta os artefatos gerados pela Análise do Domínio e Reengenharia, buscando obter as especificações das classes, sem se preocupar ainda com os detalhes de implementação. O objetivo é desenvolver uma arquitetura
genérica para a família de sistemas do domínio e sua reutilização posterior.
Nesta atividade são realizados os seguintes
1. Refinar o modelo de classes do domínio com base
nos conceitos do domínio adquiridos na elaboração do glossário, Relatório da Análise de Viabilidade, modelo de features e outros diagramas de
modelagem;
2. Definir o tratamento de cada feature alternativa e
opcional que não tenha sido feito na atividade
anterior em termos de como ele será mapeada ou mesmo se será excluída, registrando a decisão e os motivos;
3. Continuar refinando o modelo de classes até que ele
se torne realmente um modelo de projeto, isto é, contenha todos os atributos, operações e métodos identificados. É preciso levar em consideração que o escopo de genericidade do domínio deve ser
definido pelas diretrizes de viabilidades levantadas anteriormente;
4. Refinar ou criar outros modelos que sejam
interessantes para registrar características importantes do domínio; e
5. Tomando por base os modelos gerados até
este ponto, os requisitos e o conhecimento em geral do domínio projetar a arquitetura para a família de aplicações.
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.
Quando falamos de desenvolvimento para
reuso devemos pensar no domínio para que se possa fazer componentes que sejam
realmente reutilizáveis. Para se fazer
componentes podemos pensar em dois tipos de domínios:
O próprio domínio ao qual a aplicação
pertence.
Considerado especializado, só para aquela
área.
Refere-se aos segmentos de mercado, como
saúde, serviços financeiros,
Considerado mais genérico, pode ser
utilizado por várias aplicações de domínio vertical.
Refere-se a serviços comuns a diversas áreas,
como por exemplo interface de usuário,
gerenciamento de sistemas, gerenciamento de tarefas.
OBS.
Desenvolvimento da aplicação integração
vertical
Desenvolvimento dos contextos de domínio e
de aplicações envolvidas integração horizontal.
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
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 planeamento do
projeto: fase de análise e planeamento.
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.
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
Produtos de software. Componente Processos de software. Processo
Tecnologia de software. Componente
O domínio pode tornar-se mais complexo e difícil de ser avaliado ou transcrito, consoante a área em que um determinado projeto esteja inserido.
Atualmente, 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 fatores que possam ter impacto no produto pretendido. No entanto, quanto maior o número fatores, mais
complexo o processo se torna, e maior é o número de situações que devem ser tidas em conta.
As observações efetuadas 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 contato com os artefatos 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 efetuar 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 projeto 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.
Em relação ao projeto:
O simples reuso tende a minimizar os riscos,
porque menos partes do produto necessitam serem codificadas e a qualidade dos
componentes reusáveis é geralmente alta. Em relaçao à organizaçao:
Um conjunto grande de riscos existe sobretudo
devido à dificuldade em se prever quais e como os componentes serão reusados.
Nenhum componente reusável é produzido.
Componentes existem mas não são encontrados.
Muito tempo para entender e avaliar o componente
(falhas na documentação).
Componentes não são reusados devido a sua baixa
qualidade.
Componentes não são reusados porque não atendem
a requisitos funcionais.
Componentes não são reusados porque não atendem
a requisitos técnicos.
Empresa pode não estar preparada para o reuso, ou
Impossibilidade de definir se reuso está
caminhando na direção certa, ou se está
sendo viável.
Novos processos e aplicação de técnicas
avançadas (complexas).
Superestimar os ganhos de tempo.
Desperdício de esforço: a criação de um
componente reusável custa cerca de 2 a 3
vezes mais que um componente não
reusável.
Esforço mal direcionado (desenvolvimento
Evolução da tecnologia.
Não limitar o reuso a simplesmente reuso de
código. O código representa menos de 25% do custo de desenvolvimento do produto.
Aquisição externa: avaliar qualidade, histórico,
contrato legal, aspectos de segurança.
Arquitetura genérica dos componentes reusáveis
pode prejudicar desempenho em sistemas críticos.
Dependência de linguagens de programação. Dependência de empresas externas.
Concentrar no reuso de componentes de
um domínio específico.
Focar o esforço na criação de pequenos
componentes mais especializados.
Focar em encapsulamento e abstração da
informação.
Prover uma boa documentação sobre o
componente.
Desenvolver componentes livres de falhas.
Focar na qualidade dos componentes (e
O reuso depende da natureza do negócio da
empresa, do tamanho de sua equipe e de seus recursos financeiros.
Detalhes técnicos influenciam o grau de
reuso alcançado pela organização.
Acompanhar a evolução de tecnologias emergentes.
Comprometimento total tanto dos gerentes
quanto dos desenvolvedores, divulgação constante do programa de reuso e
manutenção da equipe são fatores de sucesso.
Fatores políticos podem minar a eficácia do
programa de reuso e devem ser reprimidos pela alta gerência.
Riscos existem, mas bem gerenciados
trazem maiores benefícios que outras
O reuso é global, pode ser aplicado por
qualquer organização para qualquer projeto de software.
Reuso é uma estratégia de médio-longo
