Identificação dos elementos

Identifique os elementos, com base nas necessidades dos requisitos. A identificação dos elementos pode resultar de uma perspectiva estática da revisão dos requisitos e da identificação dos elementos claramente evocados, que é uma forma de modelagem de domínio. Isso pode mostrar outros elementos identificados como estando no domínio da aplicação ou considerados necessários ao examinar os requisitos para a parte do sistema a ser projetada. Esta identificação também pode acontecer a partir da identificação das principais abstrações quando da definição da arquitetura.

A identificação dos elementos deve também aplicar uma perspectiva dinâmica pela revisão dos cenários de uso do sistema (ou subsistema) e identificar os elementos necessários para suportar o comportamento. Esse comportamento pode ser um cenário de utilização na perspectiva de um usuário externo ou, durante o design de um subsistema, uma responsabilidade atribuída ao subsistema que tem um comportamento algorítmico complexo. Considere a aplicação do Padrão Entidade-Controle-Fronteira para identificar os elementos necessários para suportar o cenário, ou aplicar outros padrões identificados na arquitetura que especificam os elementos que serão utilizados para suportar determinados aspectos do cenário.

Se você estiver projetando um sistema em tempo real, inclua elementos para representar eventos e sinais que lhe permitam descrever os excitadores assíncronos do comportamento que o sistema deve responder. Eventos são especificações de interessantes ocorrências no tempo e no espaço que normalmente (se forem satisfatórios), exigem alguma resposta do sistema. Sinais representam mecanismos assíncronos utilizados para comunicar certos tipos de eventos no sistema.

Se existem elementos de revisões prévias no design ou de frameworks selecionados ou outros elementos reutilizáveis, reutilize-os sempre que possível. Veja Guideline: Reutilização de Software.

Depois de identificar os elementos, dê um nome significativo para cada. Cada elemento deve ter também uma descrição, a fim de que os membros da equipe, que trabalham em conjunto para aperfeiçoar e implementar o design, possam entender o papel que cada elemento desempenha.

Baseando-se nestas informações, a identificação dos elementos pode ser aplicada várias vezes no design de apenas uma parte do sistema. Embora não exista uma estratégia correta para várias revisões, elas podem ser feitas em um nível mais genérico e, em seguida, em um mais específico, ou em um nível (abstrato) de análise e, em seguida, um nível de design.

Comportamento dos elementos

Para identificar o comportamento dos elementos, revise os cenários e atribua adequadamente o comportamento para os participantes colaboradores. Se um determinado uso do sistema ou subsistema puder ter vários resultados possíveis ou seqüências variantes, abranja cenários suficientes para garantir que o design esteja robusto para suportar as possibilidades.

Ao atribuir comportamento aos elementos, considere a aplicação do Padrão Entidade-Controle-Fronteira ou outros padrões identificados na arquitetura.

O comportamento pode ser representado como uma simples declaração de responsabilidade, ou pode ser uma detalhada especificação de operação. Use o nível adequado de detalhe para comunicar decisões importantes de design dando a liberdade para a tomada de decisões adequadas sobre a implementação assim que essas tarefas ocorrerem.

Evite demasiada identificação de comportamento apenas da perspectiva da modelagem de domínio. Inclua apenas os comportamentos que são realmente necessários - comportamentos identificados pela revisão de cenários necessários do uso do sistema.

O comportamento deve ser entendido como uma responsabilidade de um elemento, bem como uma interação entre dois elementos no contexto de algum comportamento mais amplo do sistema ou subsistema. A última parte disto levará o desenvolvedor a identificar os relacionamentos entre os elementos que são necessários.

Relacionamentos de elemento de design

Os relacionamentos entre os elementos necessários para o comportamento devem ser projetados. Isto pode ser simplesmente a identificação da capacidade de travessia de um elemento para outro, ou então a necessidade de gerenciar uma associação entre os elementos. Os relacionamentos podem ser projetados com mais detalhes, a medida do necessário. Isto pode incluir: característica facultativa, multiplicidade, se o relacionamento é uma dependência simples ou uma associação gerenciada, e assim por diante. Estas decisões que orientam a implementação de detalhes acontecem de melhor forma no nível de design, onde é mais fácil ver como todas as peças se integram.

Evite definir muitos relacionamentos baseando-se nos relacionamentos do domínio da aplicação. Inclua apenas os relacionamentos que são necessários com base nos requisitos. Por outro lado, uma combinação de conhecimento sobre os requisitos e conhecimento sobre o domínio pode levar a algumas decisões específicas sobre os relacionamentos, tais como a característica facultativa e a multiplicidade.

Classes de Análise e YAGNI

As classes de análise são usadas para identificar os locais iniciais onde deva existir funcionalidade no sistema. Elas são os primeiros passos para compreender onde o comportamento será realizado no design e na implementação. Por exemplo, uma classe de entidade poderá inicialmente representar todos os comportamentos de um trabalhador, tais como o armazenamento de informações pessoais e o cálculo do valor de um salário. Poucas hipóteses são feitas sobre a forma como será o design final neste ponto. As classes de análise servem para garantir que o comportamento necessário esteja representado em algum lugar do sistema, e não para criar um design perfeito.

As classes de análise permitem que você comece o design a partir de abstrações, de forma que os detalhes do sistema dependam dessas abstrações e não o contrário. Na classe Empregado, a noção de empregado deve começar com a idéia de alguém que trabalha para a empresa, que tem responsabilidades e recebe benefícios. É mais fácil de criar um design a partir desta idéia simples. A complexidade do design deverá emergir das idéias abstratas do que o design deve fazer. Isto também contribuirá para manter um baixo acoplamento e uma alta coesão.

YAGNI - You Aren't Going to Need It - (Você Não Vai Precisar Disso) é uma abordagem para design onde o desenvolvedor cria apenas design e implementação suficientes para abordar a funcionalidade necessária. Nenhuma suposição é feita sobre reutilização ou possíveis usos futuros do software. O software evolui quando os requisitos do sistema demandam por mais funcionalidade e robustez.

As primeiras classes criadas sob uma perspectiva YAGNI são muito semelhantes � s classes de análise. Você não sabe o quão complexo é o calculo do salário de seus empregados, então você assume que esta funcionalidade é bastante coesa com tudo o que a classe Empregado deve fazer. À medida que você compreende o desenvolvimento dos requisitos, as classes de análise evoluem para um grupo de padrões e classes de colaboração que melhor suportam o comportamento do sistema. Por exemplo, o cálculo dos salários pode ser transferido para um padrão que trate todos os diferentes tipos de cálculo de salário (horas extra, comissões, etc.), aumentando, assim, a coesão interna da classe.

Use as classes de análise para definir um lugar inicial onde o comportamento do sistema deva ser colocado, e adicione apenas o comportamento suficiente para satisfazer a perspectiva YAGNI. As classes de análise evoluirão para classes de design concretas à medida que mais comportamento seja adicionado e o design seja re-fatorado. Veja Guideline: Evoluir o Design.