Desenvolvendo Sistemas Orientados a Objetos
Desenvolvimento de uma Etapa
A Fase Evolutiva do desenvolvimento de um sistema compreende uma
sucessão de etapas de trabalho. Cada etapa configura-se na forma de um mini-ciclo que
abrange as atividades de especificação, projeto, construção, teste e generalização. Como
explicado na seção Processo de Desenvolvimento Evolutivo (Figura 4: Ciclo evolutivo),
essas atividades não são executadas seqüencialmente, mas sim de forma organizada e
coordenada. Assim, os produtos dessas atividades vão sendo gerados concorrentemente, de
maneira que a experiência em uma atividade possa influenciar no produto das outras,
permitindo a reversibilidade. Portanto, somente considera-se finalizada cada uma dessas
atividades quando toda a etapa estiver fechada, ou seja, quando todas as demais atividades
tiverem sido concluídas.
Para fins de apresentação neste documento, os produtos de cada atividade
foram dispostos em seqüência, facilitando sua visualização e entendimento. Desta maneira
a seção está dividida em:
♦
♦
♦
♦
♦
♦
♦
Explorando os Casos de Uso
Especificando a Estrutura Estática das Classes
Especificando o Comportamento das Classes
Projetando as Classes
Construindo as Classes
Testando
Generalizando
O resultado do item Explorando os Casos de Uso é a identificação das classes
de interface com usuário a partir da descrição do funcionamento dos casos de uso.
A modelagem das classes é demonstrada nos itens Especificando a Estrutura
Estática das Classes - que relaciona as classes e seus atributos, e Especificando o
Comportamento das Classes - que identifica as operações, a partir da análise de
colaboração entre as classes.
Projetando as Classes apresenta as decisões de como as classes serão
codificadas. Também relaciona as classes de apoio necessárias para a construção do
sistema.
O item Construindo as Classes apresenta a codificação obtida pela
implementação das classes e fornece também as visões Componente, Processo e
Distribuição (ver Figura 8: Visões do Sistema , na seção Arquitetura do Sistema).
57
Desenvolvendo Sistemas Orientados a Objetos
Os itens Testando e Generalizando discutem os aspectos referentes a validação,
verificação e otimização do código do sistema.
Explorando os Casos de Uso
Os casos de uso definem os requisitos funcionais do sistema. Cada caso de uso
dará origem a uma ou mais telas, de forma que o sistema possa apoiar o usuário nas suas
tarefas. A seguir, cada caso de uso presente na Etapa A será explorado em mais detalhes,
através de protótipos de tela e de diagramas de seqüência.
Cadastrar Cliente
É muito interessante o uso de protótipo nesta fase do trabalho, pois através dele
pode-se oferecer uma visão concreta do sistema, o que facilita bastante a comunicação com
os usuários que estão auxiliando na especificação. Não é importante que o protótipo seja
fiel à aparência final da tela. É preciso lembrar que o papel do protótipo, neste caso, não é
especificar a aparência, mas sim esclarecer o funcionamento desejado do sistema e auxiliar
na identificação das classes de negócio, seus atributos e operações.
Geralmente, o protótipo contém apenas grupos de campos legendados e botões
que representam as funcionalidades. Nada de conexões com banco de dados, acesso a
colunas de tabelas ou programação dos botões. O protótipo deve ser bastante simples e não
deve tomar muito tempo para ser obtido. Caso contrário, deixa de ser um protótipo e passa
a ser a construção efetiva do sistema.
58
Desenvolvendo Sistemas Orientados a Objetos
Figura 17: Protótipo para o caso de uso Cadastrar Cliente
Juntamente com o protótipo de tela, é elaborado um diagrama de seqüência
para demonstrar o funcionamento do caso de uso. O diagrama de seqüência apresenta uma
interação típica entre usuário e sistema, organizada na escala do tempo. Geralmente, são
necessários vários diagramas para explicar um caso de uso, um diagrama para cada tipo de
interação possível. Por exemplo, para o caso de uso Cadastrar Cliente, foram utilizados três
diagramas para representar as interações de inclusão, modificação e exclusão de clientes.
59
Desenvolvendo Sistemas Orientados a Objetos
Figura 18: Diagrama de seqüência para Cadastrar Cliente – Inclusão
<<actor>>
<Vendedor>
Ven:<Vendedor>
FormCadCliente:CadastrarCliente
Cli:Cliente
Abrir
Obter Clientes
Informações do Primeiro Cliente
Incluindo
Novo Cliente
Preparar para Inclusão
Informações de Cliente
Confirmar
Incluir
Sair
No diagrama de seqüência, um objeto é representado por um retângulo acima
de uma linha vertical pontilhada. O nome do objeto é seguido pelo nome da classe à qual
ele pertence, separado por dois pontos (ex.: Cli:Cliente significa um objeto denominado Cli
pertencente à classe Cliente). A figura do homenzinho foi colocada no diagrama para
salientar que aquele objeto é um Ator, e não um objeto do sistema.
As linhas verticais representam a existência do objeto no tempo, para indicar os
instantes de sua participação durante a interação. As setas indicam as mensagens enviadas
de um objeto para outro. Elas podem ser interpretadas como ações desempenhadas pelo
usuário (ex.: clicar botão btnNovoCliente), chamadas de operações (ex.:
Cliente.PrepararParaInclusao) ou respostas resultantes de operações (ex.: Informações do Primeiro
Cliente). Outras interpretações são também possíveis, porém estas são as mais comuns.
O diagrama apresentado na Figura 18 pode ser lido da seguinte maneira:
1. O vendedor solicita ao sistema a abertura da janela de Cadastrar Cliente.
2. A janela solicita à classe Cliente que retorne a relação dos clientes cadastrados.
3. Após receber a resposta, a janela exibe as informações do primeiro cliente da
relação.
60
Desenvolvendo Sistemas Orientados a Objetos
4. O vendedor informa à janela que quer cadastrar um novo cliente.
5. A janela solicita que a classe Cliente prepare um espaço para os dados do novo
cliente.
6. O vendedor digita as informações do novo cliente.
7. O vendedor informa à janela a confirmação da inclusão.
8. A janela solicita que a classe Cliente efetue a inclusão.
9. O vendedor comanda o fechamento (saída) da janela.
É importante lembrar que os diagramas de seqüência não fazem parte da
especificação do sistema, apenas servem como uma forma de identificação das classes e
operações necessárias. Logo, não necessitam ser completos e precisos. Talvez para um
sistema em tempo real seja imperativo alta precisão no diagrama de seqüência, mas para o
caso dos sistemas organizacionais não existe esta necessidade.
Além de permitir a inclusão de novos clientes, o caso de uso Cadastrar Cliente
oferece meios para modificar os dados de um cliente já cadastrado ou ainda excluí-lo do
cadastro. Assim, são necessários mais dois diagramas para explicar estas funcionalidades.
Figura 19: Diagrama de seqüência para Cadastrar Cliente – Modificação
<<actor>>
<Vendedor>
Ven:<Vendedor>
FormCadCliente:CadastrarCliente
Cli:Cliente
Abrir
Obter Clientes
Informações do Primeiro Cliente
Modificando
Selecionar Cliente
Obter Cliente Selecionado
Informações de Cliente
Editar
Preparar para Alteração
Alterações de Cliente
Confirmar
Alterar
Sair
61
Desenvolvendo Sistemas Orientados a Objetos
A leitura do diagrama sobre modificação pode ser a seguinte:
1. O vendedor solicita ao sistema a abertura da janela de Cadastrar Cliente.
2. A janela solicita à classe Cliente que retorne a relação dos clientes cadastrados.
3. Após receber a resposta, a janela exibe as informações do primeiro cliente da
relação.
4. O vendedor seleciona o cliente cujos dados devem ser alterados.
5. A janela solicita à classe Cliente que retorne os dados do cliente selecionado.
6. Após receber a resposta, a janela exibe as informações do cliente selecionado.
7. O vendedor informa à janela que quer editar os dados do cliente.
8. A janela solicita que a classe Cliente prepare os dados do cliente para serem
editados.
9. O vendedor digita as alterações dos dados do cliente.
10. O vendedor informa à janela a confirmação da alteração.
11. A janela solicita que a classe Cliente efetue a alteração.
12. O vendedor comanda o fechamento (saída) da janela.
Observe que as primeiras mensagens apresentadas na Figura 19 são idênticas
às do diagrama que define a inclusão. Isto porque ambos os diagramas explicam o
comportamento da mesma janela que, ao abrir, sempre obtém os clientes cadastrados e
exibe as informações do primeiro. Os diagramas muitas vezes se sobrepõem, pois uma
interação pode envolver procedimentos já demonstrados em outra interação.
62
Desenvolvendo Sistemas Orientados a Objetos
Figura 20: Diagrama de seqüência para Cadastrar Cliente – Exclusão
<<actor>>
<Vendedor>
Ven:<Vendedor>
FormCadCliente:CadastrarCliente
Cli:Cliente
Abrir
Obter Clientes
Informações do Primeiro Cliente
Excluindo
Selecionar Cliente
Obter Cliente Selecionado
Informações de Cliente
Excluir
Confirmar Exclusão
Excluir
Sair
A leitura do diagrama sobre exclusão pode ser a seguinte:
1. O vendedor solicita ao sistema a abertura da janela de Cadastrar Cliente.
2. A janela solicita à classe Cliente que retorne a relação dos clientes cadastrados.
3. Após receber a resposta, a janela exibe as informações do primeiro cliente da
relação.
4. O vendedor seleciona o cliente que deve ser excluído do cadastro.
5. A janela solicita à classe Cliente que retorne os dados do cliente selecionado.
6. Após receber a resposta, a janela exibe as informações do cliente selecionado.
7. O vendedor informa à janela que quer excluir o cliente do cadastro.
8. Para evitar uma exclusão acidental, o vendedor deve confirmar que deseja
mesmo excluir aquele cliente.
9. A janela solicita que a classe Cliente efetue a exclusão.
10. O vendedor comanda o fechamento (saída) da janela.
Com estes três diagramas, obtém-se uma visão clara do funcionamento
desejado para o caso de uso Cadastrar Cliente. Não foram representadas todas as
63
Desenvolvendo Sistemas Orientados a Objetos
possibilidades de interações, mas apenas as mais importantes. Outros diagramas poderiam
ter sido usados para apresentar situações de exceção, como por exemplo o cancelamento de
uma inclusão. Optou-se aqui por considerar essas situações como subentendidas, e portanto
elas não aparecem nos diagramas. Cada caso exigirá uma abordagem diferente, a partir da
avaliação de custo/benefício de se avançar no detalhamento das possíveis interações.
Definir Categorias de Produtos
O desenho do protótipo para o caso de uso Definir Categorias de Produtos
compreende as seguintes características: a visualização da hierarquia de categorias e
subcategorias de produtos, a possibilidade de seleção, alteração e exclusão de uma
categoria desejada, e ainda a inclusão de nova categoria ou subcategoria.
Figura 21: Protótipo para Definir Categorias de Produtos
Quando o funcionamento do caso de uso não é muito complicado e extenso,
pode-se expressar várias interações em apenas um diagrama de seqüência. Um título
próximo à margem esquerda pode ser usado para indicar o início da descrição de cada
interação, como demonstrado na Figura 22.
64
Desenvolvendo Sistemas Orientados a Objetos
Figura 22: Diagrama de seqüência para Definir Categorias de Produtos
<<actor>>
<Almoxarife>
Alm:<Almoxarife>
FormDefCategProduto:DefinirCategoriasDeProdutos
Cat:CategoriaDeProdutos
Abrir
Obter Categorias
Inform.Categorias/Subcategorias
Incluindo
Nova Categoria
Preparar para Inclusão
Informações de Categoria
Incluir
Nova Subcategoria
Preparar para Inclusão
Informações de Subcategoria
Incluir
Modificando
Selecionar Categoria
Obter Categoria Selecionada
Informações de Categoria
Alterar
Preparar para Alteração
Alterações de Categoria
Alterar
Excluindo
Selecionar Categoria
Obter Categoria Selecionada
Informações de Categoria
Excluir
Confirmar Exclusão
Excluir
Sair
65
Desenvolvendo Sistemas Orientados a Objetos
Registrar Produto
O caso de uso Registrar Produto requer uma busca de informações sobre as
categorias definidas no sistema. Isso está indicado no protótipo da tela através da caixa de
combinação (combo box) com o título “Categoria”.
Figura 23: Protótipo para Registrar Produto
Esta busca de informações é apresentada no diagrama de seqüência com a
inclusão de um objeto da classe CategoriaDeProdutos, que fará parte da colaboração para a
realização do caso de uso.
66
Desenvolvendo Sistemas Orientados a Objetos
Figura 24: Diagrama de seqüência para Registrar Produto
<<actor>>
<Almoxarife>
FormRegProd:RegistrarProduto
Alm:<Almoxarife>
Prod:Produto
Cat:CategoriaDeProdutos
Abrir
Obter Lista de Categorias
Obter Produtos
Informações do Primeiro Produto
Incluindo
Novo Produto
Preparar para Inclusão
Informações de Produto
Confirmar
Incluir
Modificando
Selecionar Produto
Obter Produto Selecionado
Informações de Produto
Editar
Preparar para Alteração
Alterações de Produto
Confirmar
Alterar
Excluindo
Selecionar Produto
Obter Produto Selecionado
Informações de Produto
Excluir
Confirmar Exclusão
Excluir
Sair
67
Desenvolvendo Sistemas Orientados a Objetos
Pesquisar Produto
Este caso de uso estabelece apenas uma consulta aos objetos cadastrados.
Assim, a partir da indicação da categoria e/ou subcategoria desejada, o usuário tem a
oportunidade de visualizar os produtos que pertencem àquele grupo. Ao selecionar um
produto, os respectivos atributos são exibidos na tela.
Figura 25: Protótipo para Pesquisar Produto
Uma característica interessante dos diagramas de seqüência é que eles
apresentam uma seqüência de interação entre diversos objetos pertencentes a classes
provenientes de diferentes partes da Arquitetura do Sistema (ver Figura 6: Definição da
arquitetura do sistema). Por exemplo, na Figura 26 são utilizados os seguintes objetos:
♦ Ven:<Vendedor> representa um Ator, definido no Modelo de Casos de Uso
♦ FormPesqProd:PesquisarProduto representa uma janela, ou seja, um objeto
de
interface com usuário
♦ Prod:Produto representa um objeto de negócio
♦ Cat:CategoriaDeProdutos representa um objeto de negócio
68
Desenvolvendo Sistemas Orientados a Objetos
Figura 26: Diagrama de seqüência para Pesquisar Produto
<<actor>>
<Vendedor>
Ven:<Vendedor>
FormPesqProd:PesquisarProduto
Prod:Produto
Cat:CategoriaDeProdutos
Abrir
Obter Lista de Categorias
Lista Categorias/Subcategorias
Selecionar Categoria
Obter Lista Produtos da Categ
Lista de Produtos da Categoria
Selecionar Produto
Obter Produto Selecionado
Informações de Produto
Sair
Cadastrar Vendedor
O caso de uso Cadastrar Vendedor é muito simples, portanto segue a mesma idéia
da utilização de apenas um diagrama de seqüência para apresentar inclusão, alteração e
exclusão de vendedores. O protótipo da tela e a lógica das interações são apresentados nas
figuras a seguir.
69
Desenvolvendo Sistemas Orientados a Objetos
Figura 27: Protótipo para Cadastrar Vendedor
70
Desenvolvendo Sistemas Orientados a Objetos
Figura 28: Diagrama de seqüência para Cadastrar Vendedor
<<actor>>
<Gerente>
Ger:<Gerente>
FormCadVendedor:CadastrarVendedor
Ven:Vendedor
Abrir
Obter Vendedores
Informações dos Vendedores
Incluindo
Novo Vendedor
Preparar para Inclusão
Informações de Vendedor
Confirmar
Incluir
Modificando
Selecionar Vendedor
Obter Vendedor Selecionado
Informações de Vendedor
Editar
Preparar para Alteração
Alterações de Vendedor
Confirmar
Alterar
Excluindo
Selecionar Vendedor
Obter Vendedor Selecionado
Informações de Vendedor
Excluir
Confirmar Exclusão
Excluir
Sair
Registrar Recebimento de Produtos
O registro do recebimento dos produtos adquiridos com os fornecedores
consiste na verificação do pedido, registro dos produtos efetivamente recebidos e
atualização do estoque. Porém, nesta Etapa A, apenas a atualização do estoque será
71
Desenvolvendo Sistemas Orientados a Objetos
desenvolvida, enquanto as demais funcionalidades estão previstas no desenvolvimento da
Etapa D (ver seção Planejamento das Etapas Evolutivas).
Figura 29: Protótipo para Registrar Recebimento de Produtos
Observe, na Figura 30, a mensagem Calcular Novo Estoque. Esta mensagem é
enviada e recebida pelo mesmo objeto, a janela FormRegRecProd. Na prática, significa
chamada a uma operação do próprio objeto. A representação desse tipo de mensagem é
importante quando se deseja realçar processamentos internos ao objeto, porém isto só deve
ser feito para aquelas operações que denotam relevância ao entendimento da seqüência
como um todo.
72
Desenvolvendo Sistemas Orientados a Objetos
Figura 30: Diagrama de seqüência para Registrar Recebimento de Produtos
<<actor>>
<Almoxarife>
Alm:<Almoxarife>
FormRegRecProd:RegistrarRecebimentoDeProdutos
Prod:Produto
Cat:CategoriaDeProdutos
Abrir
Obter Lista de Categorias
Selecionar Categoria
Obter Lista Produtos da Categ
Selecionar Produto
Obter Produto Selecionado
Informação de Estoque Atual
Preparar para Alteração
Qtde Adquirida
Calcular Novo Estoque
Confirmar
Atualizar Estoque
Sair
Registrar Venda
Registrar Venda é o caso de uso mais complexo da Etapa A. Ele envolve duas
telas e ainda uma chamada à tela de outro caso de uso – Cadastrar Cliente. Além da classe de
negócio Venda, há a participação de outras classes de negócio, como Vendedor, Cliente, Produto
e ItemDeVenda. Fazem parte também o ator <Vendedor> e as classes de interface com usuário
RegistrarVenda, PesquisarVenda e CadastrarCliente.
O protótipo de tela da classe RegistrarVenda é apresentado na Figura 31 e
contém os campos diretamente envolvidos no caso de uso, além dos botões que oferecem
várias opções de uso. A classe PesquisarVenda, cujo protótipo é apresentado na Figura 32,
constitui um diálogo para atender à funcionalidade de pesquisa das vendas cadastradas. A
classe CadastrarCliente pertence ao caso de uso Cadastrar Cliente, que foi definido no início
desta seção.
73
Desenvolvendo Sistemas Orientados a Objetos
Figura 31: Protótipo para Registrar Venda
Figura 32: Protótipo para o diálogo Pesquisar Venda
Quatro diagramas importantes foram identificados para descrever as interações
deste caso de uso. São eles:
♦
♦
♦
♦
Inclusão com cliente já cadastrado
Inclusão com cadastramento do cliente
Modificação
Exclusão
74
Desenvolvendo Sistemas Orientados a Objetos
“Inclusão com cliente já cadastrado” significa que uma nova venda será
registrada, porém o nome do cliente será selecionado em uma lista construída a partir do
cadastro de clientes. Por sua vez, “Inclusão com cadastramento do cliente” representa as
situações em que o cliente em questão não está cadastrado no sistema, o que exige seu
cadastramento durante a inclusão da nova venda. “Modificação” e “Exclusão” significam
as interações de manutenção das vendas já cadastradas, apresentando, também, a
funcionalidade de pesquisar venda.
Figura 33: Diagrama de seqüência para Registrar Venda – Inclusão com cliente já cadastrado
<<actor>>
<Vendedor>
Ven:<Vendedor>
FormRegVenda:RegistrarVenda
Cli:Cliente
Prod:Produto
Ven:Vendedor
Venda:Venda
Item:ItemDeVenda
Abrir
Obter Lista de Vendedores
Obter Lista de Clientes
Obter Lista de Produtos
Preparar para Inclusão
Informações de Venda
Indicar Vendedor
Indicar Cliente
Novo Item de Venda
Preparar para Inclusão
Indicar Produto
Informações de Item de Venda
Confirmar
Incluir
Incluir
Atualizar Estoque
Sair
75
Desenvolvendo Sistemas Orientados a Objetos
Figura 34: Diagrama de seqüência para Registrar Venda – Inclusão com cadastramento do cliente
<<actor>>
<Vendedor>
Ven:<Vendedor>
FormRegVenda:RegistrarVenda
Cli:Cliente
Prod:Produto
Ven:Vendedor
Venda:Venda
Item:ItemDeVenda
FormCadCliente:CadastrarCliente
Abrir
Obter Lista de Vendedores
Obter Lista de Clientes
Obter Lista de Produtos
Preparar para Inclusão
Informações de Venda
Novo Cliente
Abrir para Inclusão
Informações de Cliente
Confirmar
Sair
Indicar Vendedor
Novo Item de Venda
Preparar para Inclusão
Indicar Produto
Informações de Item de Venda
Confirmar
Incluir
Incluir
Atualizar Estoque
Sair
76
Desenvolvendo Sistemas Orientados a Objetos
Figura 35: Diagrama de seqüência para Registrar Venda – Modificação
<<actor>>
<Vendedor>
Ven:<Vendedor>
FormRegVenda:RegistrarVenda
Cli:Cliente
Prod:Produto
Ven:Vendedor
Venda:Venda
Item:ItemDeVenda
FormPesqVend:PesquisarVenda
Abrir
Obter Lista de Vendedores
Obter Lista de Clientes
Obter Lista de Produtos
Pesquisar
Abrir
Número da Nota Fiscal
Confirmar
Obter Venda
Obter Itens de Venda
Informações de Venda
Preparar para Alteração
Alterações de Venda
Selecionar Item de Venda
Preparar para Alteração
Alterações de Item de Venda
Alterar
Confirmar
Alterar
Atualizar Estoque
Sair
77
Desenvolvendo Sistemas Orientados a Objetos
Figura 36: Diagrama de seqüência para Registrar Venda – Exclusão
<<actor>>
<Vendedor>
Ven:<Vendedor>
FormRegVenda:RegistrarVenda
Cli:Cliente
Prod:Produto
Ven:Vendedor
Venda:Venda
Item:ItemDeVenda
FormPesqVend:PesquisarVenda
Abrir
Obter Lista de Vendedores
Obter Lista de Clientes
Obter Lista de Produtos
Pesquisar
Abrir
Número da Nota Fiscal
Confirmar
Obter Venda
Obter Itens de Venda
Informações de Venda
Excluir Venda
Confirmar Exclusão
Excluir
Excluir
Atualizar Estoque
Sair
Especificando a Estrutura Estática das Classes
Os diagramas de seqüência são o ponto de partida para a identificação das
classes necessárias. Além das classes de negócio, são também determinadas as classes de
interface com usuário, que definem os componentes visuais que comporão o sistema (ver
Figura 6: Definição da arquitetura do sistema).
As classes de negócio identificadas através dos diagramas de seqüência são
apresentadas na Figura 37. Como este estudo de caso é simples, coincidiu de todas as
classes já terem sido previstas na seção Identificação das Principais Classes de Negócio.
Normalmente surgem muitas outras classes, pois em um sistema maior e mais complexo
não seria possível identificar todas as classes durante aquela Fase Exploratória – lembre-se
que o objetivo daquela fase é apenas obter uma relação das principais classes.
78