O modelo de domínio é um dos passos mais importantes na análise OO, por decompor um domínio em conceitos.
Podemos definir o modelo de domínio em uma ilustração de classes conceituais (ou objetos de domínio).
Em outras palavras, ele é uma perspectiva conceitual de objetos em uma situação real do mundo. Ele nos auxilia na compreenção dos termos e conceitos, bem como seus relacionamentos.
O escopo do modelo de domínio é limitado pelos cenários descritos no caso de uso.

Um modelo de domínio não mostra artefatos ou classes de software. Note que modelo de domínio é diferente de camada de domínio, esta segunda representa uma camada de software com regras de negócio abaixo da camada de UI (UserInterface ou Apresentação).
O modelo de domínio não é um modelo de dados. Pode existir classes no modelo que não tenham atributos.

O que é Classe Conceitual
De modo informal, é uma idéia, coisa ou objeto. Mas formalmente uma classe conceitual pode ser considerada em termos do seu símbolo, da sua intensão e da sua extensão.

• Símbolo – palavra ou imagem que representa uma classe conceitual.
• Intensão – a definição de uma classe conceitual.
• Extensão - conjunto de exemplos aos quais a classe conceitual se aplica.

Exemplo:
Em um evento de transação de Emitir Nota Fiscal, podemos denomina-la como símbolo “Emitir NF”. A intensão de Emitir NF é “registrar de uma transferência de propriedade sobre um bem ou uma atividade comercial”. E a sua extensão são todas as “Notas Fiscais Emitidas” existentes no universo.

Referências

LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao Processo Unificado. Bookman, 2007.

Por não existir um padrão de como escrever um caso de uso e incentivado pelo PU (Processo Unificado) que possibilita utilizarmos somente o que for necessário. O Caso de Uso acabou tendo diversos formatos do que deve constar em seu conteúdo.

Para se aprofundar mais sobre esse assunto recomendo a leitura do livro “Writing Effective Use Case – Cockburn, Alistair”.

Dentro os diversos modelos de Caso de Uso, podemos dizer que os principais tópicos que temos que escrever são:

Fluxo principal:

• Não contém nenhuma condição ou desvio;
• Típico caminho que satisfaz os objetivos dos interessados.

Pré-condição:

• Condições que antecedem o caso de uso e devem ser informados ao leitor;
• São sempre assumidas como verdadeiras;
• Descreve um estado do sistema.

Pós-condição:

• O que deve ser verdade ao termino do caso de uso bem sucedido ou estado final do caso de uso.

Fluxo alternativo ou extensões:

• Descreve as condições e exceções que o fluxo principal podem tomar;
• Relação de 1 pra N com o fluxo principal;
• Descreve condições como algo que poder ser detectado pelo sistema ou pelo autor;
• Quando o fluxo for grande, pode ser expressado como outro caso de uso.

Diretrizes:

• Utilizar estilo essencial de redação, onde é expresso a intenção do usuário e as responsabilidades do sistema;
• Deixe de fora a interface do usuário;
• Focar nos objetivos dos atores, pois os casos de uso devem descreve-los.

Exemplo: O cliente (ator) tem a intenção de adicionar produtos ao carrinho e depois compra-los.
Caso de Uso: Adicionar ao carrinho, Comprar o produto.

• Iniciar os nomes de caso de uso sempre com um verbo;
• Operações do tipo CRUD (Create, Restore, Update, Delete), crie um único caso de uso denominado gerenciar .

Exemplo: Gerenciar usuários

• Observações: Alguns autores utilizam o verbo manter ao invés de gerenciar para operações CRUD.

O que são Requisitos?

É o mapeamento das propriedades que um software deve ter para atender um problema em especial.

Ele deve descrever os entendimento dos objetivos dos usuários e traduzir esses objetivos em funcionalidades do sistema.

Definições:

• Condição ou capacidade necessária para o usuário resolver um problema ou atingir um objetivo.
• Condições ou capacidade que deve ser atingida ou possuída por um sistema ou componente de sistema para satisfazer um contrato, padrão, especificação, ou outro documento de formalidade.
• Representação documentada de uma condição ou capacidade.

Objetivos dos Requisitos:

• Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o sistema deve fazer.
• Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos do sistema.
• Definir fronteiras do sistema (ou delimitar o sistema).
• Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema.
• Definir uma interface de usuário para o sistema, focando nas necessidades e metas dos usuários.

Tipos de Requisitos:

Funcionais: Definem a funcionalidade do software, função que o sistema deve realizar para tender os objetivos do usuário.
Definem O QUE o sistema deve fazer, sem a preocupação de COMO fazer.

Não funcionais: Definem as qualidades do software.

Classificação dos requisitos FURPS+

É um sistema para a classificação de requisitos, que auxilia o analista a identificar a qual propósito as informações obtidas (objetivos do usuário e caracteristica do software) se destinam.

Funcionalidade (Functionality):

• Representa todo o aspecto funcional do sistema.

Usabilidade (Usability):

• Tempo de treinamento para um usuário se tornar produtivo.
• Tempo de duração desejado para determinada operação no sistema.
• Ajuda on-line, documentação do usuário e material de treinamento.

Confiabilidade (Reliability):

• Disponibilidade.
• Tempo de correção – tempo permitido para indisponibilidade quando ocorre uma falha.
• Precisão.
• Número máximo de defeitos (bugs/KLOC – mil linhas de código).
• Categorias de bugs – bugs devem ser categorizados por nível de impacto.

Performace ou Desempenho (Performance):

• Tempo de resposta para uma transação.
• Troughput (ex: transações por segundos).
• Capacidade (ex: transações concorrentes).
• Operação Parcial (Situação do sistema aceitável quando estiver prejudicado de alguma forma).
• Uso de rescursos: memória, espaço em disco, comunicação, etc.

Suportabilidade (Supportability):

• Padrão de codificação.
• Convesão de nomenclatura.
• Bibliotecas de classes.
• Utilitários de manutenção.

+ (Plus):

• Outros(Design, implementação, interface, físicos).

Prorização de Requisitos:

Essencial: sistema não entra em funcionamento.

Importante: não impedem o funcionamento do sistema.

Desejável: não impedem a entrada em funcioanemto do sistema sem a sua implementação.

Como escrever os requisitos:

O PU (Processo Unificado) define alguns modelos de documentos e processos que auxiliam o analista (e todo a equipe de desenvolvimento) a identificar e escrever requsitos.

Dentre os diversos tipos de documentos a serem escritos, podemos citar:

• Documento de Visão
• Documento de Caso de Uso
• Especificação Suplementar
• Glossário

Até mais

O que é um Caso de Uso?

Caso de uso é “uma seqüência de ações executadas por um sistema que gera um resultado de valor observável para um determinado agente” (RUP – Rational Unified Process).

Em outras palavras caso de uso é uma narrativa em texto, utilizada para descobrir e registrar requisitos. É uma coleção de cenários relacionados de sucesso e fracasso, que descreve um ator utilizando o sistema para atingir um objetivo.

“Note que casos de uso não são diagramas, são textos. Enfocar os diagramas de caso de uso UML, de valor secundário, em vez do importante texto do caso de uso, é um erro comum para novatos”. Craig Larman.

Casos de uso são requisitos funcionais (descrevendo funções do sistema e seu ambiente), sendo um dos principais meios para obtenção de captura de comportamentos do sistema. Ele serve como um contrato estabelecido entre o cliente e os desenvolvedores. É uma das principais fontes de informações atividades de análise, design e teste.

Por enfatizar nos objetivos e perspectivas do usuário, o Caso de Uso possibilita uma redução (ou extinção) das listas de detalhes de características usadas antigamente, e foca nas funcionalidades que aplicam estas características, tornando mais fácil sua leitura e entendimento.

Um dos pontos mais difíceis é aprender como determinar em que nível de detalhe os casos de uso devem “começar e terminar”. Onde as características terminam e os casos de uso começam, e onde os casos de uso terminam e o design começa? Os casos de uso ou os requisitos do software devem estabelecer “o que” o sistema executa, mas não “como” ele executa.

Definições

Ator: é qualquer coisa que apresente algum comportamento, pode ser por exemplo uma pessoa, um caixa, um computador, outro sistema.

Tipos de ator:

• Principal: satisfaz os objetivos do usuário por meio de serviços no sistema.
• Suporte: fornece um serviço para o sistema.
• Bastidor: tem interesse no caso de uso, mas não como um ator principal ou bastidor. Por exemplo, um orgão governamental responsável por impostos.

Cenários: é uma sequência específica de ações e interações entre atores e o sistema.

Segue um link para o blog de Antonio Passos, onde ele em alguns posts aborda conceitos de casos de usos e suas realizações sendo um ótimo complemento para o assunto abordado.

Referências

LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao Processo Unificado. Bookman, 2007.

RUP 2002.05.00 (Portugues)

Até o próximo

Pessoal, encontrei um vídeo com uma palestra sobre Domain Driven Design, no Blog da Localweb.

Achei bem legal pois ele completa um pouco o post anterior.

Enjoy!