Análise e Desenho Orientados por Objetos (2/4)

By: Adail Retamal

Abstract: Parte 2 de 4. Arquétipos e UML em Cores. Início da modelagem do domínio de negócio.

Na edição anterior falamos sobre alguns fundamentos da Análise e Desenho Orientados por Objetos (OOAD). Foi proposto, como lição de casa, que o leitor pensasse sobre um estacionamento de automóveis e quais são os objetos que se destacam nesse domínio de problema. Poderíamos ter consultado especialistas no assunto, donos de estacionamentos ou pesquisado na Internet.

A idéia aqui é obter informações suficientes para esboçar um modelo de objetos primordial, que nos forneça uma visão abrangente do negócio a ser automatizado, por enquanto sem muitos detalhes.

    Construindo um modelo abrangente

Para obtermos as informações sobre o negócio precisamos da ajuda de especialistas no domínio do problema, que podem ser os proprietários, os funcionários e até consultores externos. Se você realmente fez sua lição de casa deve ter em mãos uma série de informações a respeito do funcionamento de um estacionamento. De qualquer forma, as informações a seguir servirão de guia para nossa discussão. Faça as adaptações para o seu caso.

A documentação a seguir é um exemplo típico de anotações feitas durante as apresentações que os especialistas fazem para a equipe do projeto:

  • O cliente pode ser um usuário avulso (por hora ou pernoite) ou mensalista (manhã, tarde, noite, dia todo). A identificação é feita pela placa do veículo. Um cliente pode ter vários veículos e cada veículo pode estar sob um plano diferente. Clientes avulsos não são cadastrados;
  • Os clientes mensalistas podem escolher uma data de pagamento nos dias 5, 10, 15 e 20 de cada mês;
  • A rede de estacionamentos possui vários endereços. Os clientes podem estacionar em qualquer um deles;
  • Quando um usuário deixa o veículo para estacionar, o funcionário da recepção identifica o plano correspondente e registra a entrada do veículo. Quando o cliente retornar para retirar o veículo, o funcionário registra a saída e realiza a cobrança, caso seja avulso;
  • O pagamento avulso segue a seguinte tabela de preços: R$7,00 para a 1a hora, R$4,00 para a 2a e R$2,00 para as demais horas. O valor mensal para o dia todo é de R$120,00. O valor mensal por período é de R$50,00. O pernoite custa R$14,00. Os valores da tabela podem ser alterados.

Entretanto, não nos limitamos apenas a escrever, mas também rascunhamos diagramas mostrando os objetos e seus relacionamentos. Veja na Figura 1 um esboço de um diagrama de classes de alto nível. Ele pode ter sido feito em um quadro (branco ou negro), ou numa folha de papel grande, talvez até usando notinhas autocolantes para cada objeto, durante as entrevistas.

Hide image
OOParkClasses

Figura 1. Esboço inicial do modelo do domínio

Eu usei o editor de modelos do Delphi 2006, dentro de uma aplicação ECO usando ASP.NET, que será desenvolvida no restante desta série. Para criar a sua, use o menu File|New>Other e na categoria Delphi for .NET Projects escolha o item ECO ASP.NET Web Application. Clique na aba Model View, que fica junto com o Project Manager e o Data Explorer, geralmente no canto superior direito da tela. Abra o pacote Package1 e dê um clique duplo no diagrama Package1 para abri-lo.

Selecione na ToolPalette o ícone ECO Class, clique em algum lugar do diagrama para criar uma nova classe e digite o nome dela. Para criar uma associação entre classes, clique no ícone Association, clique na primeira classe e arraste o mouse para a segunda classe. Selecione a associação para poder alterar suas propriedades, conforme a Figura 1.

O foco aqui é descobrir os componentes principais do negócio e como eles se relacionam. Não tente detalhar muito. Estamos apenas entendendo como o negócio funciona. Por enquanto esqueça a interface com o usuário, banco de dados, linguagem de programação e outros detalhes técnicos.

Uma pergunta que frequentemente se faz é: Como chegamos a esse esboço? Existem muitos caminhos. Um bom ponto de partida é ler a documentação e sublinhar os substantivos (nomes) e os verbos (ações). Os substantivos são candidatos a objetos ou a atributos (dados), e os verbos nos dão boas dicas sobre as funções (métodos) dos objetos.

Entretanto, durante as apresentações dos especialistas no domínio é possível identificar os principais objetos, muitas vezes explicitados pelos próprios especialistas. Mas sempre é bom validar nossas percepções com eles, fazendo perguntas e tentando prever como nosso modelo responde às exigências do negócio.

    Como ler o modelo de objetos?

De acordo com a Figura 1, observamos que um cliente está relacionado com vários veículos. Um veículo está relacionado com a tabela de preços, que define seu plano de valores. Uma estada está referenciando um veículo, é registrada por dois funcionários (na entrada e na saída) e é realizada em um estacionamento, que emprega vários funcionários.

Note que existe um relacionamento direto entre a estada e o estacionamento. Porém, poderíamos descobrir o estacionamento através dos funcionários que registram a estada. Às vezes fazemos isso para simplificar o modelo e / ou por questões de melhoria de performance.

O modelo deve implementar as exigências da documentação levantada e responder às perguntas do negócio. Por exemplo: Quantas estadas foram feitas em um certo estacionamento durante um período especificado? Qual o valor total correspondente? Imagine outras questões importantes e verifique se o modelo pode respondê-las satisfatoriamente.

Da forma como está, nosso modelo já nos fornece uma boa visão sobre o negócio de estacionamentos, mas podemos torná-lo melhor e mais fácil de ler. Para isso vamos adicionar uma dimensão a mais, classificando as classes de acordo com seu propósito dentro do sistema e identificando-as através de um código de cores, de acordo com o arquétipo correspondente. Mas o que é um arquétipo mesmo?

    Os quatro arquétipos

arquétipo. s.m. 1 modelo ou padrão passível de ser reproduzido em simulacros ou objetos semelhantes; 2 idéia que serve de base para a classificação dos objetos sensíveis; 3 Derivação: por extensão de sentido: qualquer modelo, tipo, paradigma. (Dic. Houaiss da Língua Portuguesa).

Por essa definição, um arquétipo é diferente de um estereótipo, que é “algo que se adequa a um padrão fixo ou geral”. Em outras palavras, um estereótipo deve ser seguido de forma rígida, enquanto um arquétipo especifica um modelo que é seguido “mais ou menos”.

Além de definir o propósito primordial de um elemento, o arquétipo também especifica algumas propriedades e funções desse elemento, incluindo possíveis relacionamentos com outros elementos. Para identificá-los, usamos cores e, no caso de diagramas UML, estereótipos com os seus nomes.

Já falei sobre isso na edição anterior, mas vamos conhecer melhor os quatro arquétipos básicos.

    Momento-Intervalo

Hide image
Representa algo que necessita ser registrado, por razões de negócio ou até mesmo legais, que ocorre em algum momento no tempo ou durante um intervalo de tempo. São atividades, eventos e serviços. Um momento-intervalo também pode ter “mi-detalhes”, ou seja, ser composto por pequenas etapas do evento total.

Exemplos: Uma venda é algo que acontece num certo momento. Uma estada é o período de tempo que o veículo fica sob a responsabilidade do estacionamento.

Para identificar esse arquétipo usamos a cor rosa e o estereótipo <<moment-interval>>. Também se usa a sigla MI. Para os detalhes, usamos o estereótipo <<mi-detail>>.

    Pessoa-Lugar-Coisa

Hide image
Representa uma pessoa (física ou jurídica), um certo local (endereço, casa, privado ou público) ou algum objeto, geralmente concreto. São entidades que devem ser registradas no sistema por desempenharem papéis nas atividades (momentos-intervalos). Uma mesma pessoa pode participar de eventos distintos através de papéis diferentes. Identificamos esse arquétipo com a cor verde e o estereótipo correspondente: <<party>>, <<place>> ou <<thing>>. Sua sigla, em inglês, é PPT.

    Papel

Hide image
É a representação de um papel que é desempenhado por alguma pessoa, lugar ou coisa, em um determinado evento do negócio (momento-intervalo). É mais comumente aplicado a pessoas, mas é possível utilizá-lo com lugares e até mesmo com coisas. No artigo anterior dei o exemplo de um aeroporto, que pode desempenhar o papel de local de origem, destino ou escala de um vôo. Sua cor é o amarelo e o estereótipo é <<role>>.

    Descrição

Hide image
É como um item num catálogo, definindo as características de uma determinada coisa, lugar ou até mesmo pessoa (menos comum, mas possível). Usado para concentrar dados comuns a diversos objetos, possibilitando perguntas de negócio interessantes, como a quantidade de objetos de um determinado tipo. Aparece na cor azul (quase cinza, dependendo da ferramenta de modelagem) e usa-se o estereótipo <<description>>.

Por que é importante reconhecer o arquétipo de cada objeto? Um arquétipo já nos diz muita coisa sobre um objeto, oferecendo características, funções e relacionamentos que nos ajudam a definir melhor cada um sem, no entanto, nos forçar a seguir o modelo. Podemos ganhar bastante em tempo e precisão seguindo as recomendações que os arquétipos nos oferecem.

Ao aplicarmos esses conceitos em nosso modelo de objetos, identificamos os seguintes arquétipos, que estão descritos na Tabela 1.

Classe

Arquétipo

Veículo

Coisa

Cliente

Pessoa ou Papel

Funcionário

Pessoa ou Papel

Estada

Momento-Intervalo

Estacionamento

Lugar

Tabela de Preços

Descrição

Tabela 1. Objetos e seus arquétipos

Há uma indefinição com relação às classes Cliente e Funcionário. Obviamente elas compartilham atributos (nome, endereço, RG, etc.) e métodos, relacionados à pessoa do cliente ou funcionário. Aqui temos duas opções:

  • Usar herança, criando uma classe abstrata Pessoa, com os atributos e métodos comuns, e derivando dela as outras duas classes. As três seriam identificadas com o arquétipo Pessoa-Lugar-Coisa (verde);
  • Usar composição, criando uma classe concreta Pessoa, com os atributos e métodos comuns, e relacionando as outras classes com ela. A classe Pessoa seria verde (Pessoa-Lugar-Coisa) e as classes Cliente e Funcionário ficariam amarelas, pois seriam papéis desempenhados por uma pessoa.

Qual das opções é a melhor? Isso depende do que queremos. Se usarmos herança, estamos decidindo que uma pessoa pode ser um cliente OU um funcionário, mas não ambos. A herança é como um estereótipo, onde descendentes devem seguir fixamente. Também é possível usar o polimorfismo para manipular objetos descendentes diferentes a partir da definição da classe superior.

Se escolhermos a composição, decidimos que uma pessoa pode desempenhar qualquer um dos dois papéis, simultaneamente ou não (essa é uma decisão de negócio) e mesmo assim podemos referenciar a pessoa correspondente. Não há polimorfismo, mas pode-se definir uma interface para manipular objetos diferentes através dela.

Geralmente o uso de herança leva a uma hierarquia fixa e de manutenção mais difícil, com pouca flexibilidade. Em muitos casos é preferível usar a composição para garantir maior liberdade e possibilitar extensões de forma mais fácil. No restante dessa série daremos preferência à composição sempre que possível.

    Nosso modelo colorido!

Adicionando a dimensão da cor ao nosso modelo, juntamente com alguns pequenos detalhes às classes, chegamos ao nosso modelo abrangente inicial, mostrado na Figura 2.

Hide image
Click to see full-sized image

Figura 2. Modelo abrangente do domínio

    UML em Cores?

As cores adicionam uma dimensão a mais em um diagrama, como se fossem camadas extras de informação, aumentando a quantidade de conteúdo que podemos expressar sem ocupar mais espaço. Mas isso não é novidade. Mesmo nos diagramas Entidade-Relacionamento já se usava cores distintas para identificar áreas afins naquele monte de tabelas. Por exemplo: financeiro em vermelho, controle de estoque em azul, contabilidade em verde, etc.

Identificamos os arquétipos usando as quatro cores básicas, em tons pastéis por serem mais suaves: rosa, amarelo, verde e azul. Outro motivo é porque as “notinhas autocolantes” também são encontradas nessas cores, o que facilita seu uso durante a modelagem inicial.

Além de tornarem o modelo mais agradável de ver, as cores identificam imediatamente o propósito de cada classe, oferecendo uma compreensão muito maior sobre o negócio e as entidades participantes.

O livro de referência sobre a modelagem em cores é “Java Modeling in Color with UML”, de Peter Coad, Eric Lefebvre e Jeff De Luca.

    Para Casa

Agora que você já aprendeu mais sobre os arquétipos e sobre o domínio do problema, faça a revisão no modelo para verificar se é uma boa simulação da realidade, tentando responder a perguntas de negócio, necessidades de relatórios, estatísticas etc.

Especifique novos atributos e métodos para as classes e até mesmo outras classes que não foram identificadas ainda. Tenho certeza que podemos chegar a um modelo bem interessante após um período de análise e verificação. Lembre-se: todo o nosso sistema dependerá desse modelo! Não imagine que sairá com um modelo definitivo da primeira vez. A análise e o projeto são resultados de várias iterações, pois cada vez que olhamos o modelo e estudamos o negócio, reconhecemos diferentes aspectos e descobrimos necessidades adicionais.

No próximo artigo vamos finalizar esse modelo, aprender um pouco mais sobre os arquétipos e começar nosso projeto usando o Delphi 2006, com uma aplicação ECO usando ASP.NET. Até lá!

Server Response from: ETNASC02