Início de uma Iteração de Construção

Para iniciar uma iteração, lembre que certos refinamentos são feitos antes de iniciar a análise detalhada da funcionalidade desejada na iteração
O capítulo que inicia agora trata de análise, ou da elaboração de um modelo conceitual

analise.gif (9568 bytes)

Elaboração de um Modelo Conceitual

Objetivos

Criar um modelo conceitual inicial
Distinguir entre atributos corretos e incorretos
Adicionar conceitos de descrição, quando apropriado
Comparar e contrastar os termos conceito, tipo, interface e classe

Introdução

O modelo conceitual é o artefato mais importante criado durante a análise
O modelo conceitual ilustra os conceitos importantes do domínio do problema, suas associações e atributos
Falaremos de associações e atributos nos próximos capítulos
Levantar um conjunto rico e expressivo de conceitos (objetos) durante a análise ajuda muito a conduzir as fases de projeto e implementação
É importante lembrar que os conceitos levantados aqui são do domínio do problema e não conceitos associados a software

Modelos conceituais

Ao fazer análise OO, a decomposição do domínio do problema utiliza objetos e não funções ou processos como na análise estruturada
Exemplo de um modelo conceitual (com conceitos, associações e atributos)
- Apenas a parte diagramática está sendo mostrada
- UML permite associar descrições mais detalhadas dos conceitos, atributos, etc.

9-1.gif (5832 bytes)

Criar o modelo conceitual ajuda a elaborar o glossário, definindo os termos importantes do domínio do problema
- Muito importante para a comunicação entre os envolvidos (clientes e desenvolvedores)
Modelos conceituais não representam entidades de software mas conceitos do domínio do negócio
- Exemplo correto

9-2.gif (1599 bytes)

Exemplos errados

9-3.gif (3403 bytes)

Cuidado! Alguns profissionais acham correto introduzir responsabilidades (ou operações) no modelo conceitual
- Embora ninguém ache certo introduzir métodos (que implementam operações) no modelo conceitual

Estratégias para identificar conceitos (objetos)

Regra fundamental: é melhor ter conceitos demais (muitos conceitos de granularidade pequena) do que conceitos de menos no modelo conceitual
Novos conceitos podem ser descobertos com tempo (quando se está identificando associações ou atributos, por exemplo) e a elaboração de um modelo conceitual é portanto uma atividade iterativa
Na modelagem de dados para bancos de dados, há um critério de modelagem que diz que algo sobre o qual não precisamos lembrar nada não precisa entrar no modelo conceitual
- Com o ponto de visto de persistência, a regra faz sentido
- Mas na modelagem OO, objetos com apenas comportamento (sem atributos) também são importantes (embora raros) e não devem ser excluídos do modelo

Usando a lista de categoria de conceitos

Conceitos são comumente descobertos nas categorias da tabela seguinte
- Os exemplos são referentes aos domínios de uma loja e reserva de passagem aérea

Categoria de Conceito	Exemplos
Objetos físicos ou tangíveis	Terminal Ponto De Venda (TPDV) Aeronave
Especificações, projetos ou descrições de coisas	Especificação de produto Descrição de um vôo
Lugares	Loja Aeroporto
Transações (um momento notável)	Venda, Pagamento Reserva
Detalhes de transação (Line item)	Item de detalhe de uma venda
Papeis de pessoas	Caixa Piloto
Coleções de outras coisas (containers)	Loja, Prateleira Aeronave
Coisas dentro das coleções	Item Passageiro
Outros sistemas externos a nosso sistema	Sistema de autorização de cartão de crédito Sistema de controle de tráfego aéreo
Conceitos abstratos	Fome Acrofóbia (medo de altura)
Organizações	Departamento de vendas Voamos Baixo, Ltda.
Eventos	Venda, Roubo, Reunião Vôo, Desastre, Aterrissagem
Processos (frequentemente não é representado como conceito, mas pode ocorrer)	Fazer a venda de um produto Fazer uma reserva de lugar num vôo
Regras e políticas	Política de devolução Política de cancelamento
Catálogos	Catálogo de produtos Catálogo de peças
Registros de assuntos financeiros, de trabalho, de contratos, legais	Recibo, Plano de contas, Contrato de emprego Log de manutenção
Instrumentos e serviços financeiros	Linha de crédito Estoque
Manuais, livros	Manual do empregado Manual de reparos

Achando conceitos através de substantivos

Uma técnica simples para a identificação de conceitos é de isolar os substantivos nas descrições textuais dos Use Cases
- Muitos dos substantivos serão conceitos ou atributos
Exemplo: Use Case expandida "Comprar Item com Dinheiro Vivo"

Ação do ator	Resposta do sistema
O Use Case inicia quando um cliente chega a um caixa munido de TPDV com itens a comprar
O caixa registra a identificação de cada item Se houver mais itens, o caixa pode informar a quantidade também	Determina o preço do item e adiciona a informação ao total da transação de venda A descrição e preço do item corrente são exibidos
Ao completar a entrada dos itens, o caixa indica este fato ao TPDV	Calcula e apresenta o total da venda
O caixa informa o total da venda ao cliente
O cliente efetua o pagamento com dinheiro, possivelmente maior que o total da venda
O caixa registra a quantidade de dinheiro recebida	Mostra o valor do troco ao cliente Gera um recibo impresso
O caixa deposita o dinheiro recebido e extrai o troco a devolver O caixa entrega o troco e o recibo impresso ao cliente	Faz log da venda completada
O cliente sai da loja com os itens comprados

Alguns desses substantivos são conceitos (objetos), outros são atributos de conceitos
- Falaremos mais sobre as diferenças em outro capítulo
- Uma regra útil: Se pensarmos sobre um conceito X como número ou texto no mundo real, ele pode ser um atributo; caso contrário, sempre será um conceito
  - Na dúvida, crie um conceito separado
  - Exemplo: Destino é um atributo de um vôo ou um conceito separado?
    - É um conceito separado (pensamos no destino como sendo um aeroporto)

Conceitos candidatos para o domínio do TPDV

Usando as técnicas acima, temos a seguinte relação de candidatos:

TPDV	Especificação de produto
Item	Item de detalhe de uma venda
Loja	Caixa
Venda	Cliente
Pagamento	Gerente
Catálogo de produtos

Relatórios são objetos?

Um recibo é um relatório
Deveria ser um conceito (objeto)
A favor de excluir:
- Um recibo é apenas um relatório de uma venda
- Incluí-lo no modelo conceitual não seria útil porque toda sua informação é derivada de outros objetos
A favor de incluir
- Um recibo tem um papel importante nas regras de negócio porque permite que o cliente devolva itens comprados
Na primeira iteração de desenvolvimento, os Use Cases não consideram a devolução do produto e não incluiremos o objeto Recibo
- Em outra iteração, poderá ser incluído

Modelagem do mundo não real

Em certos domínios de problema, os conceitos são muito abstratos
Exemplo: domínio de redes de computadores ou telecomunicações
- Conceitos possíveis são: Mensagem, Conexão, Diálogo, Protocolo, etc.

Modelando descrições

Não se deve incluir como atributos descrições de conceitos a instâncias desses conceitos por dois motivos
- Repetição de informação
- A descrição some se não houver instância
Exemplo: Não está correto incluir a descrição de um produto no conceito Produto
- É melhor criar um novo conceito DescriçãoDeProduto que descreve instâncias de Produtos

9-8.gif (3287 bytes)

Outro exemplo: O conceito Vôo deveria incluir toda a descrição do vôo?
- Não! Se nenhum vôo RG321 ocorrer, a descrição do vôo RG321 deve continuar em algum lugar: é um conceito à parte

9-9.gif (4074 bytes)

Termos empregados na UML

UML não emprega a palavra "conceito"
As alternativas são tipo e classe
- A diferença entre tipo e classe é que um tipo é abstrato (sem implementação) enquanto a classe sempre inclui alguma implementação
- Portanto, o tipo é uma especificação e a classe é uma implementação (de um tipo)
- A diferença entre as duas coisas se torna mais importante durante a fase de Projeto
Por enquanto, basta dizer que usaremos "conceito" para falar do domínio do problema e "classe" para falar de entidades de software

anal1-1 programa próxima