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

Agora que sabemos quais são os principais elementos (modelo de domínio) a serem tratados na nossa aplicação, iremos planejar a implementação do site.

Para isso temos que pensar na criação da:

• camada de interface
• camada de controle
• camada de negócio
• camada de persistência de dados

Para a camada de interface, criei um protótipo.E com esse protótipo, podemos visualizar quais serão as principais funcionalidades do site, ou principais operações a serem realizadas.

Segue protótipo para o site do Juca:

De uma forma resumida, foi possível extrair deste protótipo as seguintes operações necessárias para seu funcionamento:

• GetAlbum()
• GetFigurinha()
• GetRecentesItens()
• Busca(nome)

No próximo post irei criar os diagramas de classes e sequência, para podermos iniciar a fase de desenvolvendo das operações mencionadas e criar nosso mecânismo de acesso a dados com o iBatis.

Até mais

Uma das formas de se projetar objetos de software é pensar em suas responsabilidades. Essas responsabilidades podem se tratar de um pequeno objeto a uma divisão macro do sistema.
Essas responsabilidades devem descrever o que um objeto deve fazer e o que o deve saber.

História do dia-a-dia

Suponhamos que você tenha que entregar um relatório para seu chefe sobre uma fórmula química de um produto de limpeza. Mas você não conhece nada de química.
Fácil, não é?
Você delega esta atividade a um químico, para que ele escreva o relatório da fórmula química para você.
Pronto, sem mistério ou complicação.

Atribuindo responsabilidade

O desenvolvimento de software deve ser tão fácil quando a história acima.
As responsabilidades devem ser atribuídas aos objetos que tem a informação necessária para satisfazer as responsabilidade.
Vejamos o modelo seguinte, qual é o melhor objeto para informar a quantidade de tomadas de um quarto?

Sabemos que o Quarto tem conhecimento das suas paredes, e que cada Parede tem o conhecimento da quantidade de suas suas tomadas.
Desta forma a melhor solução para aplicamos a responsabilidade de obter a quantidade de tomadas é através do objeto Quarto, que delega a cada Parede que informe sua quantidade de tomada. Assim a quantidade total de tomadas é a soma das tomadas presente em cada parede.

O método TotalTomadas() do objeto Quarto:

1
2
3
4
5
6
7
8
9

public int TotalTomadas()
{
     int ret = 0;
     foreach(Parede parede in paredes)
     {
          ret += parede.GetQtdTomadas();
     }
     return ret;
}

Para melhorar ainda mais esse trabalho, podemos criar um objeto chamado Paredes que estenda o Array (Collection) de paredes presente no objeto quarto, e criarmos um método GetTomadas() que faça o trabalho da soma das tomadas.
Assim, a nossa lista de Paredes presente no objeto Quarto ficaria com a responsabilidade de obter o total de tomadas de cada item interno e somá-los.
Desta forma o método TotalTomadas() fica assim:

1
2
3
4

public int TotalTomadas()
{
     return paredes.GetTomadas();
}

O método GetTomadas() do objeto Paredes:

1
2
3
4
5
6
7
8
9

public int GetTomadas()
{
     int ret = 0;
     foreach(Parede parede in this)
     {
          ret += parede.GetQtdTomadas();
     }
     return ret;
}

Isso nos permite reaproveitar código, pois se no projeto existisse objetos como Galpão, Prédio, etc. Poderíamos utilizar o mesmo objeto Paredes para ambos (dependendo do contexto), pois certamente, Galpão e Prédio têm paredes. Assim estaríamos evitando a duplicação de código e facilitando sua manutenção.