Professor Moderno
Trabalho Escolar: Professor Moderno. Pesquise 860.000+ trabalhos acadêmicosPor: • 2/6/2014 • 9.845 Palavras (40 Páginas) • 418 Visualizações
PARTE 3
Elaboração
Iteração 1
9
Modelo de Casos de Uso:
como Desenhar Diagramas de Seqüência do Sistema
Na teoria, não há diferença entre teoria e prática. Mas na prática há.
-Jan L. A. van de Snepscheut
.
.
OBJETIVOS
Identificar os eventos do sistema.
Criar diagramas de seqüência do sistema para os casos de uso.
Em Direção à Iteração 1
O projeto do PDV ProxGer entrou na sua primeira iteração de desenvolvimento real. Na fase de concepção, realizou-se trabalho leve nos requisitos para ajudar a decidir se o projeto valia uma investigação mais séria. Foi feito o planejamento para a primeira iteração e decidiu-se atacar um cenário simples de sucesso, pagamento com dinheiro, do caso de uso Processar Venda (sem colaborações remotas com outros sistemas). O objetivo é iniciar um projeto e uma implementação “ampla na cobertura, mas pouco profunda” que toque em muitos dos principais elementos da arquitetura do novo sistema. Na primeira iteração, serão realizadas muitas tarefas referentes ao estabelecimento do ambiente (ferramentas, pessoas, processo - de desenvolvimento
- e configuração), aspectos que serão ignorados aqui.
Em vez disso, voltaremos nossa atenção para a análise de casos de uso e de domínio. Antes de começar o trabalho de projeto na iteração 1, é útil que façamos algumas investigações adicionais do domínio do problema. Parte dessas investigações consiste no esclarecimento dos eventos de sistema de entrada e de saída relacionados com o nosso sistema, os quais podem ser ilustrados com os diagramas de seqüência da UML.
1’IJ LJ IILILANDO LJIVIL E I-’ADROES
Introdução
Um diagrama de seqüência do sistema é um artefato criado rápida e facilmente que ilustra os eventos de entrada e saída relacionados com o sistema em discussão. A UML contém uma notação na forma de diagramas de seqüência para ilustrar os eventos provenientes dos atores externos a um sistema.
9.1 Comportamento do Sistema
Antes de começar um projeto lógico de como uma aplicação de software funcionará, é necessário investigar e definir seu comportamento como uma “caixa-preta”. O comportamento do sistema é uma descrição do que o sistema faz, sem explicar como ele o faz. Uma parte dessa descrição é um diagrama de seqüência do sistema.
9.2 Diagramas de Seqüência do Sistema a!
Os casos de uso descrevem como os atores externos interagem com o sistema de software que estamos interessados em criar. Durante essa interação, um ator gera eventos reconhecidos por um sistema, geralmente solicitando alguma operação como resposta. Por exemplo, quando um caixa entra com o ID de um item, ele solicita ao sistema PDV registrar a compra daquele item. Esse evento de solicitação inicia uma
operação no sistema. o
É desejável isolar e ilustrar as operações que um ator solicita ao sistema, porque de
elas são uma parte importante da compreensão do comportamento deste. A UML in clu diagramas de seqüência, uma notação que pode ilustrar as interações de atores
e as operações iniciadas por eles.
Um diagrama de seqüência do sistema é uma figura que mostra, para o cená ri específico de um caso de uso, os eventos que os atores externos geram, sua ordem
e os eventos entre sistemas. Todos os sistemas são tratados como uma caixa-preta; a
ênfase do diagrama está nos eventos que atravessam a fronteira do sistema entre ato re e outros sistemas.
Deve ser feito um diagrama de seqüência de sistema (DSS) para a seqüência
de sucesso principal do caso de uso e para cenários freqüentes ou alternativas
complexas.
A UML não define alguma coisa chamada de diagrama de seqüência do “sistema”, mas simplesmente um diagrama de seqüência. Esta qualificação é usada aqui para enfatizar a aplicação desse diagrama UML a sistemas vistos como caixas-pretas. Mais adiante, os diagramas de seqüência serão usados em outro contexto - ilustrar o projeto de objetos de software que interagem entre si para realizar um trabalho.
9.3 Exemplo de um DSS
Um diagrama de seqüência do sistema mostra, para uma seqüência específica de
eventos dentro de um caso de uso, os atores externos que interagem diretamente com
ator externo ao
sistema •0
A caixa envolve uma
área de iteração.
* é um marcador
de uma iteração e uma
cláusula que indica que
a caixa se refere à
iteração.
valor(es) de
retorno associado(s)
com a mensagem
anterior
Uma abstração que
ignora a apresentação
e a mídia.
O retorno é opcional,
caso nada seja
retornado.
Figura 9.1 DSS para um cenário de Processar Venda.
9.4 DSSs Inter-Sistemas
Os DSSs também podem ser usados para ilustrar as colaborações entre sistemas, como entre o PDV ProxGer e o sistema externo autorizador de crédito. Entretanto, essa discussão será adiada até uma iteração posterior no estudo de caso, uma vez que esta iteração não inclui a colaboração entre sistemas remotos.
MODELO DE CASOS DE USO: COMO VESENHAR VIAGRAMAS DE EQUENCIA DO 1S1bMA 1’&J.
o sistema, o sistema (como uma caixa-preta) e os eventos do sistema que os atores geram (ver Figura 9.1). O tempo corre de cima para baixo, e a ordem dos eventos deve seguir sua ordem no caso de uso.
Os eventos de sistema podem incluir parâmetros.
Este exemplo é da seqüência típica de eventos do caso de uso Processar Venda. Ele indica que o caixa gera os eventos do sistema iniciarNova Venda, entrarltem, terminarVenda efazerPagamento.
sistema como uma caixa-preta
O nome poderia ser “PDV ProxGer”, mas Sistema’ fica mais simples.
O “:“ e o sublinhado implicam uma instância, e são explicados mais tarde no capitulo sobre a notação de diagrama de seqüência na UML.
Cenário de Processar Venda
‘o
-----o
---o
troco a devolver, recibo
142 UTILIZANDO I. PADROES
9.5 DSSs e Casos de Uso
Um DSS mostra eventos de sistema para uma seqüência, ou cenário, de um caso de uso; portanto, é gerado a partir da inspeção de um caso de uso (ver Figura 9.2).
Caixa [ Sistema
Cenário simples de Processar Venda iniciarNovaVenda()
para pagamento com dinheiro:
1. O Cliente chega a um ponto de . .
pagamento equipado com um PDV, entrarltem(itemlD, quantidade)
trazendo vários bens ou serviços que
deseja comprar.
2.0 Caixa inicia uma nova venda. 1. dcral 1
3. O Caixa digita o identificador do item. * rmais itens
4. O Sistema registra a linha de item da
venda e exibe a descrição, o preço do - _______________________________________________
tem e o total parcial corrente. terminarVenda ()
O Caixa repete os passos 3 e 4 até que
indique ter terminado.
5. O Sistema apresenta o total, com os total com impostos
impostos já calculados. ..-
6. O Caixa informa o total ao Cliente
e solicita o pagamento. fazerPagamento(quantia) 9 7
7. O Cliente paga e o Sistema trata
o pagamento.
___________________________________ troco a devolver, recibo
Figura 9.2 Diagramas de seqüência do sistema são derivados dos casos de uso.
9.6 Eventos do Sistema e a Fronteira do Sistema
Para identificar os eventos do sistema, é necessário ser claro na escolha da fronteira
do sistema, conforme discutido no capítulo anterior sobre os casos de uso. Com
o objetivo de desenvolvimento de software, geralmente se escolhe o software (e
talvez o hardware) do próprio sistema para ser a fronteira. Neste contexto, o evento
de sistema é um evento externo que estimula diretamente o software (ver Figura
9.3).
Vamos considerar o caso de uso Processar Venda, de modo a identificar eventos
de sistema. Antes de mais nada, devemos determinar os atores que interagem diretamente
com o sistema de software. O cliente interage com o caixa, porém, para este
cenário simples de pagamento com dinheiro, não interage diretamente com o sistema
PDV - apenas o caixa interage com este último. Desta forma, o cliente não é um
gerador de eventos de sistema, somente o caixa o é.
IVIOUhLU U LASOS ui Uso: COMO DESENHAR DIAGRAMAS DE SEQÜÊNCIA DO SISTEMA 143
Caixa Sistema
iniciarNovaVenda()
entraritem
(itemlD,_quantidade) ________________
terminarVenda()
fazerPagamento
(quantia) 1
o
fronteira do sistema
Figura 9.3 Definição da fronteira do sistema.
9.7 Como Dar Nomes a Eventos e Operações de Sistema
Os eventos de sistema (e suas operações de sistema associadas) devem ser expressos em termos de intenção, e não em termos do meio físico de entrada de dados ou em relação aos elementos de tela da interface.
Começar o nome de um evento de sistema com um verbo também melhora a
clareza (adicionar..., entrar..., terminar..., efetuar...), conforme mostrado na Figura 9.4.
Esse procedimento enfatiza a orientação de comando que estes eventos têm.
Assim, “entrarltem” é melhor que “escanear” (isto é, usar o scanner a laser) , porque capta a intenção da operação. Ao mesmo tempo, permanece abstrato e sem compromissos com relação a escolhas e decisões do projeto sobre a interface que será usada para captar o evento do sistema.
Sistema
nome melhor II
entrarltem(itemlD, quantidade)
escanear(ltemID, quantidade)
nome pior
Figura 9.4 Escolha os nomes de eventos e de operações abstratos.
144 UTILIZANDO UML E PADRÕES
9.8 Mostrar o Texto do Caso de Uso 9.10
Às vezes, é desejável mostrar, pelo menos, fragmentos do texto do caso de uso no cenário,
de forma a esclarecer ou melhorar as duas visões (ver Figura 9.5). O texto fornece
os detalhes e o contexto, e o diagrama resume visualmente a interação.
9.9 Os DSSs e o Glossário
Os termos mostrados nos DSSs (operações, parâmetros, dados de retorno) são bem
resumidos e podem necessitar de uma explicação adequada, de modo que, durante FaSes o trabalho de projeto, fique claro o que está entrando e o que está saindo do sistema.
Se isso não foi explicado nos casos de uso, então o Glossário poderia ser usado para
esse fim.
No entanto, como sempre acontece ao discutir a criação de artefatos que não
sejam código (o coração do projeto), isso pode parecer suspeito. Deve sempre haver
um uso verdadeiramente significativo do Glossário em caso de decisão. Caso
contrário, simplesmente teremos um trabalho desnecessário e que não acrescenta
valor.
Cenário simples de Processar Venda
para pagamento com dinheiro:
1. O Cliente chega a um ponto de : Sistema
pagamento equipado com um PDV, : Caixa
trazendo vários bens ou serviços que .
deseja comprar. iniciarNovaVenda()
2. O Caixa inicia uma nova venda.
3.0 Caixa digita o identificador do item. entrarltem(itemlD, quantidade)
4. O Sistema registra a linha de item da _____________________________________________
venda e exibe a descrição, o preço do
item e ototal parcial corrente. descrião,joLaL
* [mais itens]
O Caixa repete os passos 3 e 4 até terminarvendaQ
que indique ter terminado.
5. O Sistema apresenta o total, com os total com imfiostos
impostosja calculados. +
6. O Caixa informa o total ao Cliente
e solicita o pagamento. fazerPagamento (quantia)
7. O Cliente paga e o Sistema
processa o pagamento. ovçecã
-
Figura 9.5 DSS com texto do caso de uso.
MODELO DE CASOS DE Uso: COMO DESENHAR DIAGRAMAS DE SEQÜÊNCIA Do SISTEMA 145
9.10 DSSs no PU
Fases
Os DSSs são parte do Modelo de Casos de Uso - uma visualização das interações decorrentes dos casos de uso. Não eram explicitamente mencionados na descrição original do PU, embora seus criadores estivessem cientes e compreendessem a utilidade de tais diagramas. Os DSSs são um exemplo dos muitos artefatos possíveis resultantes de uma análise e projeto competentes ou de atividades que os documentos do PU ou do RUP não mencionam.
Concepção - Os DSSs geralmente não se justificam na fase de concepção. Elaboração - A maioria dos DSSs é criada durante a elaboração, quando então é útil para identificar detalhes dos eventos do sistema, para esclarecer quais operações importantes devem ser projetadas para lidar com esses eventos, para escrever contratos para operações (discutidos no Capítulo 13) e, possivelmente, fundamentar estimativas (por exemplo, macroestimativas com Pontos por Função não ajustados e COCOMO II).
Note que não é necessário criar DSSs para todas as seqüências de todos os casos de uso - pelo menos não ao mesmo tempo. Em vez disso, crie DSSs somente para algumas seqüências escolhidas da iteração corrente.
Finalmente, apenas poucos minutos ou meia hora deveriam ser gastos com os
DSSs.
Tabela 9.1 Amostra de artefatos do PU e sua seqüência temporal
- iniciar; r - refinar
de
Artefato
Iteração -4
Disciplina Concepção Cl Elaboração El...En Construção Ctl...Ctn Transição Tl..,T2
Modelagem Negócio Modelo de Domínio
Requisitos Modelo de Casos de Uso (DSSs)
Visão
Especificações Suplementares r
Glossário r
Projeto Modelo de Projeto i r
Documento de Arquitetura de software i
Modelo de Dados i r
Implementação Modelo de Implementação i r r
Gestão de Projeto Plano de Desenvol viment de software i r r r
Teste Modelo de Teste i r
Ambiente Pasta de Desenvolvimento i r
146 UTILIZANDO UML E PADRÕES
9.11 Leituras Adicionais
Variações de diagramas que ilustram os eventos de EIS para um sistema tratado como uma caixa-preta têm sido amplamente usadas há décadas; por exemplo, em telecomunicações, como diagramas de fluxo de chamadas. Popularizaram-se de forma especial nos métodos orientados a objetos, por meio do seu uso no método Fusion [Coleman+94], o qual forneceu um exemplo detalhado do relacionamento entre os DSSs e as operações do sistema com outros artefatos de análise e projeto.
9.12 Artefatos do PU
Na Figura 9.6, são apresentadas amostras de relacionamentos entre DSSs e outros artefatos.
Plano de Desenvolvimento de Software
Parâmetros ou dados de retorno podem ser elaborados no Glossário
Glossário
Plano
de Teste
Teste ii
Pasta de Desenvolvimento
Amostras de Artefatos do PU
Modelagem
de Negócio
Modelo de Domínio
Artefatos parciais, refinados em cada iteração.
Modelo de Casos de Uso ,-
Requisitos
Projeto
Mode
Documento de Arquitetura
tar objetos de Software
de Projeto para tratar os
eventos do
sistema.
Gestão de
Projeto
Ambiente
Figura 9.6 Amostra da influência dos artefatos do PU.
. Ii!SI
eventos foo(x)j bar(y) operaçoesdo
casos de uso textuais e dados do sistema diagramas de seqüência do sistema sistema contratos para as operações do sistema
lo
Modelo de Domínio:
Visualização dos Conceitos
Está tudo bem na prática, mas nunca funcionará na teoria.
- máxima gerencial anônima
OBJETIVOS
• Identificar classes conceituais relacionadas com os requisitos da iteração corrente.
• Criar um modelo de domírtio inicial.
• Distinguir entre atributos corretos e incorretos.
• Acrescentar, quando apropriado, classes conceituais de especificação.
• Comparar e diferenciar as visões conceituais e de implementação.
introdução
Um modelo de domínio é amplamente utilizado como fonte de inspiração para projetar objetos de software e será um dado de entrada requerido por vários artefatos subseqüentes discutidos neste livro. Portanto, é importante ler este capítulo se o leitor não estiver familiarizado com o assunto de modelagem de domínio.
O modelo de domínio ilustra as classes conceituais significativas (para os modeladores) em um domínio de problema; é o artefato mais importante a ser criado durante a análise orientada a objetos.’ Este capítulo explora as habilidades introdutórias para a criação de modelos de domínio. Os dois capítulos seguintes expandem as habilidades de modelagem do domínio - acrescentando atributos e associações.
1 Os casos de uso são um artefato importante da análise de requisitos, porém não são realmente orientados a objetos. Eles enfatizam uma visão de processo do domínio.
148 UTILIZANDO UML E PADRÕES
Identificar um conjunto rico de objetos ou de classes conceituais está no cerne _____
da análise orientada a objetos e é um esforço que vale a pena pelo retomo que traz na conce
fase de projeto e implementação. ou obj
A identificação de classes conceituais faz parte de uma investigação do domí- de dor
nio do problema. A UML contém notações na forma de diagramas de classes para
ilustrar modelos de domínio.
associ
Idéia-chave
Um modelo de domínio é uma representação de classes conceituais do mundo
real, não de componentes de software. Ele não é um conjunto de diagramas
que descreve classes ou objetos de software com responsabilidades, atribui
10.1 Modelos de Domínio
O passo mais essencialmente orientado a objetos na análise ou na investigaçao e a
decomposição de um domínio de interesse em classes conceituais e objetos individuais
- os quais nos interessam. Um modelo de domínio é uma representação visual
de classes conceituais, ou objetos do mundo real, em um domínio de problema
[M095, Fowler96j. Eles têm sido chamados modelos conceituais (o termo usado
na primeira edição deste livro), modelos de objetos do domínio e modelos de ob- Fi
jetos da análise.2 lin
O PU define um Modelo de Domínio3 como um dos artefatos que podem ser
criados na disciplina de Modelagem de Negócios.
Usando a notação UML, um modelo de domínio é ilustrado com um conjunto Idéla-cha
de diagramas de classes, nos quais não se definem operações. Ele pode mostrar:
• objetos do domínio ou classes conceituais; R
cl
• associações entre classes conceituais;
• atributos de classes conceituais. ct
l’or exemplo, a Figura 10.1 mostra um modelo de domínio parcial. Ela mostra que as
classes conceituais Pagamento e Venda são significativas neste domínio, que um Pagamento
está relacionado a uma Venda de maneira importante e que uma Venda tem
uma data e uma hora de ocorrência. Neste momento, os detalhes de notação não são
importantes.
tr
Modelos
2 Eles também estão relacionados a modelos conceituais entidades-relacionamentos, os quais são capazes de mostrar
visões puramente conceituais de domínios, mas que têm sido amplamente reinterpretados como modelo de dados para
o projeto de banco de dados. Os modelos de domínio não são modelos de dados.
As letras maiúsculas em Modelo de Domínio são usadas quando quero enfatizá-lo como um modelo oficial definido
no PU, em oposição ao conceito geral bem conhecido de “modelos de domínio”.
MODELO DE DOMÍNIO: VISUALIZAÇÃO DOS CoNcEnos 149
Figura 10.1 Modelo de domínio parcial - um dicionário visual. Os números no fim de cada linha indicam a multiplicidade, descrita em um capítulo adiante.
Idéia-chave: modelo de domínio - um dicionário visual de abstrações
Reflita um instante sobre a Figura 10.1. Ela visualiza e relaciona algumas palavras ou classes conceituais no domínio. Também ilustra uma abstração das classes conceituais, visto que há muitas coisas que se desejaria comunicar sobre registros, vendas, etc. O modelo exibe uma vista parcial, ou abstração, e ignora aquilo que (para os modeladores) são detalhes sem interesse.
A informação que ela ilustra (usando a notação UML) poderia ter, de forma alternativa, sido transmitida por texto em prosa, por sentenças no Glossário ou em um outro lugar qualquer. Entretanto, é fácil compreender os elementos discretos e seus relacionamentos nesta linguagem visual, uma vez que uma porcentagem significativa do cérebro participa do processamento visual - esse é um ponto forte dos seres humanos.
Assim, o modelo de domínio pode ser considerado um dicionário visual das abstrações, do vocabulário do domínio e do conteúdo do mesmo dignos de nota.
Modelos de domínio não são modelos de componentes de software
Um modelo de domínio, como o mostrado na Figura 10.2, é uma descrição de coisas no mundo real do domínio do problema, não de componentes de software, como uma classe em Java ou C++ (ver Figura 10.3). Portanto, os seguintes elementos não são adequados em um modelo de domínio:
associação o
atributos o
150 UTILIZANDO UML E PADRÕES
• Artefatos de software, como uma janela ou um banco de dados, a menos que o domínio que está sendo modelado seja de conceitos de software, como um modelo de
interfaces gráficas com o usuário.
• Responsabilidade ou métodos.4
o
Figura 10.2 Um modelo de domínio mostra classes conceituais do mundo real, não classes de software.
BancodeDadosDeVendas artefato de software; não
O faz parte do modelo de
domínio
Venda
_____________________ classe de software; nao
d o faz parte do modelo de
a domínio
hora
imprimir ()
Figura 10.3 Um modelo de domínio não mostra artefatos ou classes de software.
Classes conceituais
O modelo de domínio ilustra classes conceituais ou vocabulário no domínio. De modo informal, um conceito é uma idéia, uma coisa ou um objeto. Mais formalmente, uma classe conceitual pode ser considerada em termos do seu símbolo, da sua intenção e da sua extensão [M095] (ver Figura 10.4).
• Símbolo - palavras ou imagens que representam uma classe conceitual.
• Intenção - a definição de uma classe conceitual.
• Extensão - o conjunto de exemplos aos quais a classe conceitual se aplica.
Na modelagem de objetos, geralmente falamos de responsabilidades relacionadas com componentes de software, e os métodos são um conceito unicamente de software. Entretanto, o modelo de domínio descreve conceitos do mundo real, e não componentes de software. Considerar responsabilidades durante a fase de projeto é muito importante; estas não fazem, porém, parte do modelo de domínio. Um caso válido no qual podem ser mostradas responsabilidades em um modelo de domínio é quando ele inclui papéis de trabalhadores humanos (como Caixa), cujas responsabilidades o modelador deseja registrar.
visualização de um conceito do mundo real no domínio de interesse
Esta não é uma imagem de uma classe de software.
MODELO DE DOMÍNIO: VISUALIZAÇÃO DOS CONCErIOS 151
Por exemplo, considere a classe conceitual para o evento de uma transação de compra. Posso escolher nomeá-la com o símbolo Venda. A intenção de uma Venda pode determinar que ela “representa o evento de uma transação de compra e tem uma data e uma hora”. A extensão de Venda são todas as ocorrências de vendas; em outras palavras, o conjunto de todas as vendas.
1 símbolo do conceito
E
“Uma venda representa o evento de uma transação de compra. Ela tem uma data e uma hora”.
intenção do conceito d
conceito
Figura 10.4 Uma classe conceitual tem um símbolo, uma intenção e uma extensão.
Quando estamos trabalhando em um modelo de domínio, geralmente o símbolo e a intenção de um conceito têm maior interesse prático.
Modelos de domínio e decomposição
Os problemas de software podem ser complexos; a decomposição - dividir para conquistar - é uma estratégia comum para lidar com esta complexidade, pela divisão do espaço do problema em unidades compreensíveis. Na análise estruturada, o critério usado para a decomposição são os processos ou as funções. Porém, na análise orientada a objetos, a dimensão de decomposição usada é fundamentalmente realizada por meio de coisas ou entidades no domínio.
Uma distinção central entre a análise orientada a objetos e a estruturada: a divisão por classes conceituais (objetos), em vez da divisão por funções.
venda-1
venda-3
venda-2
venda-4
Portanto, uma tarefa básica da fase de análise é identificar diferentes conceitos no domínio do problema e documentar os resultados em um modelo de domínio.
152 UTILIZANDO UML E PADRÕES
Classes conceituais no domínio venda
Por exemplo, no mundo real do domínio de compra de itens em uma loja, existem as classes conceituais de Loja, Registro e Venda. Portanto, o nosso modelo de domínio, mostrado na Figura 10,5, pode incluir uma Loja, um Registro e uma Venda.
Loja Registro Venda
Figura 10.5 Modelo conceitual parcial no domínio da loja
10.2 Identificação de Classes Conceituais
Nosso objetivo é criar um modelo de domínio composto de classes conceituais interessantes ou significativas no domínio de interesse (vendas). Nesse caso, isso significa conceitos relacionados com o caso de uso Processar Venda.
No desenvolvimento iterativo, se constrói de forma incremental um modelo de domínio ao longo de várias iterações na fase de elaboração. Em cada uma, o modelo de domínio está limitado aos cenários prévios e ao cenário em consideração, ao invés de um modelo big bang, o qual tenta captar prematuramente todas as classes conceituais e relacionamentos. Por exemplo, essa iteração está limitada a um cenário de Processar Venda simplificado que contempla somente o pagamento com dinheiro; portanto, será criado um modelo parcial do domínio para refletir apenas isso - e nada mais.
Dessa forma, a tarefa central é identificar classes conceituais relacionadas com
o cenário que está sendo projetado no momento.
A seguir, propomos uma diretriz útil para a identificação de classes conceituais:
É melhor especificar em excesso um modelo de domínio com muitas classes
conceituais de granularidade fina do que subespecificá-lo.
Não pense que um modelo de domínio será melhor se tiver menos classes conceituais; a verdade tende a ser exatamente o oposto.
É comum deixar passar classes conceituais durante a fase inicial de identificação e descobri-las mais tarde, durante a consideração de atributos ou associações ou, ainda, durante a fase de projeto. Quando encontradas, elas são incorporadas ao modelo de domínio.
Não exclua um conceito somente porque os requisitos não indicam uma necessidade óbvia de lembrar informações sobre ele (um critério comum, usado na modelagem de dados para o projeto de bancos de dados relacionais, mas irrelevante para a modelagem conceitual) ou, ainda, porque o conceito não tem atributos.
E perfeitamente válido ter classes conceituais sem atributos, ou que têm um papel puramente comportamental no domínio, em vez de um papel de informação.
MODELO DE DOMÍNIO: VISUALIZAÇÃO Dos CoNcmos 153
Estratégias para identificar classes conceituais
Nas seções seguintes, são apresentadas duas técnicas:
1. Usar uma lista de categorias de classes conceituais.
2. Identificar substantivos ou frases que possam estar no lugar de substantivos. Outra técnica excelente para a modelagem do domínio é o uso de padrões de análise, que são modelos de domínio parciais criados por especialistas, usando recursos publicados, como os livros Analysis Patterns [Fowler96J e Data Model Patterns [Hay96].
Usar uma lista de categorias de classes conceituais
Comece a criação de um modelo de domínio fazendo uma lista das classes conceituais candidatas da lista de categorias de classes conceituais. A Tabela 10.1 contém muitas categorias comuns que geralmente vale a pena considerar, embora não seja necessário seguir alguma ordem de importância específica. Os exemplos são tirados do domínio da loja e do domínio de reservas de passagens aéreas.
Tabela 10.1 Lista de categorias de classes conceituais
Categoria de Classe Conceitual
Exemplos
Registro, Aeronave
Especifica çãoDeProduto, Descri çãoDe Vôo
Loja, Aeroporto
Venda, Pagamento, Reserva
LinhaDeltemDe Venda
Caixa, Piloto
Loja, Armário, Aeronave
ltem, Passageiro
SistemaAutorizaçãoDePagamentoComCrédito
ControleDoTráfegoAéreo
objetos físicos ou tangíveis
especificações, projetos ou descrição de coisas
lugares
transações
linhas de itens de transações
papéis desempenhados por pessoas
contêineres de outras coisas
coisas em um contêiner
outros sistemas de computador ou dispositivos eletromecânicos externos ao nosso sistema
classes conceituais de substantivos abstratos
organizações
eventos
processos (que geralmente não são representados como conceitos, embora possam sê-lo)
regras e políticas PolíticaDeReembolsos, PolíticaDeCancelamentos
catálogos CatálogoDeProdutos, CatálogoDePeças
registros financeiros, trabalhistas, de contratos, de assuntos legais Recibo, DiárioDeCaixa ContratoDeEmprego, DiárioDeManutenção
serviços e instrumentos financeiros LinhaDeCré dito, Ações
manuais, documentos, artigos de referência ListaDiáriadeMudançasDePreços Manua/DeConsertos
Fome, Acro fobia
DepartamentoDe Vendas, ObjetoLinhaAérea
Venda, Pagamento, Reunião,
Vôo, Acidente, Aterrissagem
VendendoUmProduto
ReservandoUmAssonto
154 UTILIZANDO UML E PADRÕES
Como encontrar classes conceituais pela identificação de substantivos e
frases que podem estar no lugar de um substantivo
Uma outra técnica útil (por sua simplicidade), proposta em [Abbott83j, é a análise lingüística: identificar os substantivos e as frases que podem estar no lugar de um substantivo, nas descrições textuais de um domínio de problema, e considerá-los como candidatos a classes conceituais ou atributos.
Deve-se tomar cuidado ao aplicar este método; não é possível um mapeamento mecânico de substantivos para classes conceituais, e as palavras em uma linguagem natural tendem a ser ambíguas.
Não obstante o dito anteriormente, trata-se de uma outra fonte de inspiração. Os casos de uso plenamente desenvolvidos fornecem excelentes descrições a serem usadas como fontes para este tipo de análise. Por exemplo, pode-se usar o cenário atual em desenvolvimento do caso de uso Processar Venda.
Cenário de Sucesso Principal (ou Fluxo Básico):
1. O Cliente chega ao ponto de pagamento do PDV com bens ou serviços para adquirir.
2. O Caixa inicia uma nova venda.
3. O Caixa digita o identificador do item.
4. O Sistema registra a linha de item de venda e apresenta uma descrição do item, o preço do mesmo e o total parcial da venda, O preço é calculado segundo um conjunto de regras de preços.
O Caixa repete os passos 3 e 4 até que indique ter terminado
5. O Sistema apresenta o total com os impostos calculados.
6. O Caixa informa ao Cliente o total e solicita o pagamento.
7. O Cliente paga e o Sistema processa o pagamento.
8. O Sistema registra a venda completada e envia as informações de venda e pagamento para o Sistemas externo de Contabilidade (para contabilização e comissões) e de Estoque (para atualizar o estoque).
9. O Sistema apresenta o recibo.
10. O Cliente sai com o recibo e os bens (se for o caso)
Extensões (ou Fluxos Alternativos):
7a. Pagamento com dinheiro:
1. O Caixa digita a quantia de dinheiro fornecida.
2. O Sistema apresenta o valor do troco e libera a gaveta de dinheiro.
3. O Caixa deposita o dinheiro fornecido e entrega o troco para o Cliente.
4. O Sistema registra o pagamento em dinheiro.
O modelo de domínio é uma visualização de conceitos e de vocabulário do domínio dignos de nota. Onde eles se encontram? Nos casos de uso. Assim, eles representam uma rica fonte a ser explorada pela identificação de frases nominais (substantivos ou frases que podem, em uma sentença, ocupar o lugar de um substantivo).
Alguns desses substantivos são candidatos a classes conceituais, outros podem se referir a classes conceituais que são ignoradas nessa iteração (por exemplo
MODELO DE DOMÍNIO: VISUAUZAÇÃO DOS CONcE]ElOs 155
“Contabilidade” e “comissões”) e ainda outros podem ser atributos. Veja a seção e o capítulo seguintes sobre atributos para uma orientação sobre como distinguir entre os dois.
Um ponto fraco desta abordagem é a imprecisão da linguagem natural; diferentes substantivos podem representar a mesma classe conceitual ou atributo, entre outras ambigüidades. Apesar disso, ela é recomendada em combinação com a técnica da Lista de Categorias de Classes Conceituais.
10.3 Classes Conceituais Candidatas para o Domínio de Vendas
A partir da Lista de Categorias de Classes Conceituais e da análise de frases nominais, geramos uma lista de candidatos a classes conceituais para o domínio. A lista está restrita aos requisitos e às simplificações que estão sendo considerados - o cenário simplificado de Processar Venda.
Registro EspecficaçãoDeProduto
Item LinhaDeltemDe Venda
Loja Caixa
Venda Cliente
Pagamento Gerente
CatálogoDeProdutos
Não existe algo que possa ser chamado de lista “correta”. Ela é uma coleção um tanto arbitrária de abstrações e vocabulário do domínio que os modeladores consideram digna de nota. De qualquer forma, seguindo as estratégias de identificação acima, listas similares serão produzidas por modeladores diferentes.
Objetos-relatório - incluir o recibo no modelo?
Um recibo é o registro de uma venda e seu pagamento, sendo uma classe conceitual relativamente proeminente no domínio de vendas. Assim, ele deveria ser mostrado no modelo? Temos alguns fatores a considerar:
• Um recibo é o relatório de uma venda. Em geral, mostrar um relatório de outra informação em um modelo de domínio não é útil porque toda a sua informação é derivada de outras fontes; ele duplica a informação que pode ser encontrada em outro lugar. Esta é uma razão para excluí-lo.
• Um recibo desempenha um papel especial em termos das regras de negócio: geralmente ele confere o direito ao portador do recibo de devolver os itens comprados pelo mesmo. Esta é uma razão para mostrá-lo no modelo.
Uma vez que a devolução de itens não está sendo considerada neste ciclo de desenvolvimento, o Recibo será excluído. Durante o ciclo de desenvolvimento que trata o caso de uso Tratar Devoluções, a sua inclusão seria justificável.
156 UIIL1LAND0 Lji\’IL E 1-’AUROES
10.4 Diretrizes para Modelagem de Domínio
Como construir um modelo de domínio
Siga estes passos para criar um modelo de domínio:
1. Liste as classes conceituais candidatas, usando a Lista de Categorias de Ur
Classes Conceituais e a identificação de substantivos relacionados com
os requisitos que estão sendo considerados.
2. Desenhe-os em um modelo de domínio.
3. Acrescente as associações necessárias para registrar os relacionamentos para os quais existe a necessidade de preservar alguma memória (discutido em um capítulo subseqüente).
4. Acrescente os atributos necessários para completar os requisitos de informação (discutido em outro capítulo mais adiante).
Um método complementar útil é aprender e copiar “padrões de análise”, discutidos
em um capítulo a seguir.
Sobre a nomenclatura e a modelagem de coisas: o cartógrafo
A estratégia do cartógrafo se aplica tanto a mapas quanto a modelos de domínio.
Fazer um modelo de domínio no espírito com que um cartógrafo trabalha:
• Usar os nomes existentes no território.
• Excluir características irrelevantes.
• Não incluir coisas que não estão lá.
Um modelo de domínio é um tipo de mapa de conceitos ou coisas em um domínio. Este espírito enfatiza o papel analítico de um modelo de domínio e sugere o seguinte:
• Os cartógrafos usam os nomes do território - eles não mudam os nomes das cidades em um mapa. Para um modelo de domínio, isso equivale a dizer use o vocabulário do domínio quando nomear classes conceituais e atributos. Por exemplo, se estiver desenvolvendo um modelo para uma biblioteca, nomeie o cliente como um “Usuário” ou “Cliente da Biblioteca” - termos usados por funcionários de bibliotecas.
• O cartógrafo exclui coisas de um mapa se não forem consideradas relevantes para a finalidade do mesmo; por exemplo, a topografia ou as populações não necessitam ser mostradas. Da mesma forma, um modelo de domínio pode excluir das- ses conceituais no domínio do problema não-pertinentes aos requisitos. Por exemplo, podemos excluir Caneta e CestoDePapéis do nosso modelo de domínio (para o conjunto corrente de requisitos), uma vez que eles não desempenham um papel óbvio digno de nota.
IVIUUbLO U1 L’oMINIo: VISUALILAÇAU Dos L0NL11 105 1/
• O cartógrafo não mostra coisas que não estão lá, como uma montanha que não existe. Da mesma forma, o modelo de domínio deveria excluir coisas que não estão no domínio do problema que está sendo considerado.
O princípio também é conhecido como a estratégia Use o Vocabulário de Domínio [Coad95].
Um engano comum ao identificar classes conceituais
Talvez o engano mais comum na criação de um modelo de domínio seja representar algo como um atributo quando ele deve ser um conceito. Uma regra prática para ajudar a evitar esse engano é a seguinte:
Se você não pensar em uma classe conceitual X como um número ou um texto no mundo real, então X provavelmente será uma classe conceitual, não um atributo.
Por exemplo, loja deve ser um atributo de Venda ou uma classe conceitual separada
Loja?
Venda Venda Loja
ou...?
loa numeroDe
_____________ _____________ Telefone
No mundo real, uma loja não é considerada um número ou texto - o termo sugere uma entidade legal, uma organização e algo que ocupa espaço. Portanto, Loja deve ser um conceito.
Como outro exemplo, considere o domínio de reservas de passagens aéreas. Destino
deveria ser um atributo de Vôo ou uma classe conceitual separada como Aeroporto?
Vôo Vôo Aeroporto
ou...?
destino nome
No mundo real, um aeroporto de destino não é considerado um número ou um texto - ele é uma coisa de grande porte que ocupa espaço. Portanto, Aeroporto deveria ser um conceito.
Em caso de dúvida, torne-o um conceito separado. Os atributos devem ser
muito raros em um modelo de domínio.
10.5 Como Resolver Classes Conceituais Semelhantes - Registro versusTPDV
TPDV é uma sigla que significa terminal de ponto-de-vendas. Em jargão de computadores, um terminal é qualquer dispositivo na ponta, ou fronteira, de um sistema,
158 UTILIZANDO UML E PADRÕES
como um PC cliente, um PDA conectado em rede sem fio, etc. Antigamente, muit antes do surgimento de terminais de PDV, as lojas mantinham um registro - um livr no qual eram registradas as vendas e os pagamentos. Posteriormente, isso acabo sendo automatizado como uma “caixa registradora mecânica”. Atualmente, ur TPDV preenche o papel do registro (ver Figura 10.6).
Um registro é algo que registra vendas e pagamentos, mais isso também é feit por um terminal de ponto-de-vendas. Contudo, o termo registro parece mais abstrat e menos orientado a uma implementação específica do que TPDV. Assim, no model de domínio, o símbolo Registro deveria ser usado em lugar de TPDV?
Antes de mais nada, observe, como regra prática, que um modelo de domínio não é absolutamente correto ou errado, e sim mais ou menos útil; é uma ferramenta de comunicação.
Pelo princípio do cartógrafo, TPDV é um termo familiar no território e, dessa form um símbolo útil sob o ponto de vista de familiaridade e comunicação. Quando o ol jetivo é criar modelos que representem abstrações independentes da implementaçã Registro torna-se atraente e útil.5 Registro pode ser considerado para representar tar to a classe comercial de um local para registrar vendas como uma abstração de váric tipos de terminais, como um TPDV.
Cada escolha tem seus méritos; Registro foi escolhido neste estudo de caso d
maneira um tanto arbitrária, mas TPDV também teria sido compreensível para os ir
teressados no projeto.
Conceitos similares com
nomes diferentes
ou?
Figura 10.6 TPDV e registro são classes conceituais similares.
10.6 Modelagem do Mundo Irreal
Alguns sistemas de software se destinam a domínios que têm muito pouca analogi
com domínios naturais ou de negócios; um software para telecomunicações é ui
Observe que, no passado, um registro era somente uma das implementações possíveis de como registrar vendas. termo adquiriu um significado genérico com o tempo.
MODELO DE DOMÍNIO: VISUALIZAÇÃO DOS CONCEITOS 159
exemplo. Ainda é possível criar um modelo de domínio nestes domínios, mais isso requer um alto grau de abstração, bem como um afastamento do que nos acostumamos a considerar em projetos mais habituais.
Por exemplo, temos aqui alguns candidatos a classes conceituais relacionados
com um dispositivo de chaveamento em telecomunicações: Mensagem, Conexão, Porta, Diálogo, Rota, Protocolo.
10.7 Classes Conceituais de Especificação ou de Descrição
A discussão a seguir pode, a princípio, parecer relacionada com um problema raro,
altamente especializado. Entretanto, a necessidade de classes conceituais de especificação (como serão definidas) é comum em muitos modelos de domínio. Assim, ela
é aqui enfatizada.
Suponha o seguinte:
• Uma instância de Item representa um item físico em uma loja; como tal, ela pode até mesmo ter um número de série.
• Um Item tem uma descrição, um preço e um itemlD que não estão registrados em qualquer outro lugar.
• Todos os que trabalham na loja sofrem de amnésia.
• Cada vez que um item físico real é vendido, uma instância de software correspondente de Item é excluída do “mundo do software”.
Com estas hipóteses, o que acontece no seguinte cenário?
Existe uma forte demanda para um hambúrguer vegetariano novo e muito apreciado - HambúrguerObjeto. A loja vende todo o seu estoque desse hambúrguer, isso implicando que todas as instâncias Item de HambúrguerObjeto são excluídas da memória do computador.
Agora, temos aqui o cerne do problema: se alguém pergunta “Quanto custam os HambúrguerObjeto?”, ninguém sabe responder, porque a memória do seu preço estava ligada às instâncias estocadas, as quais foram sendo excluídas à medida que eram vendidas, até que todas tivessem sido vendidas.
Observe também que o modelo corrente, se implementado em software, conforme descrito, tem dados duplicados. Assim, é ineficiente em termos de espaço de armazenamento, porque a descrição, o preço e o itemlD são duplicados para cada instância de Item do mesmo produto.
A necessidade de classes conceituais de especificação ou de descrição
O problema precedente ilustra a necessidade de um conceito de objetos que são especificações ou descrições de outras coisas. Para resolver o problema de Item, o que é necessário é uma classe conceitual EspeczficaçãoDeProduto (ou EspecficaçãoDeItem, DescriçãoDeProduto, etc.) que armazene informações sobre itens. Uma EspecficaçãoDeProduto não representa um Item, mas uma descrição de informações sobre itens. Observe que, mesmo se todos os itens registrados no estoque forem vendidos e suas instâncias de Item correspondentes em software forem excluídas, a EspecficaçãoDeProduto ainda permanecerá.
Os objetos de descrição ou especificação estão fortemente relacionados com as
coisas que descrevem. Em um modelo de domínio, é comum afirmar que uma EspecificaçãoDeX Descreve um X (ver Figura 10.7).
160 U IILILANDO UML E PADRÕES
A necessidade de classes conceituais de especificação é comum nos domínios de v das e produtos, bem como no domínio de manufatura, na qual é necessária uma cri ção de uma coisa manufaturada, a qual é distinta da coisa em si. O tempo e o ço são utilizados para motivar as classes conceituais de especificação porque muito comuns; este não é um conceito raro de modelagem.
tem
descrição Pior
preço
número de série
itemlD
EspecificaçãoDeProduto
Melhor
Figura 1 0.7 Especificações ou descrições sobre outras coisas. Q ““ significa uma multiplicidade de “muitos”. Ele indica que uma Especifica çãoDeProduto pode descrever muitos Itens (*)
Quando as classes conceituais de especificação são necessárias?
A seguinte diretriz sugere quando utilizar especificações:
Acrescente uma especificação ou classe conceitual de descrição (por exemplo,
EspecificaçãoDeProduto) quando:
• Houver necessidade de uma descrição sobre um item ou serviço, independentemente da existência de algum exemplar desses itens ou produtos.
• A exclusão de instâncias de coisas que elas descrevem (por exemplo, Item) resultar em uma perda de informação que precise ser mantida, devido à associação incorreta da informação com a coisa excluída.
• Esta especificação ou classe reduzir informações redundantes ou duplicadas.
Outro exemplo de especificação
Como outro exemplo, considere uma linha aérea que sofre um acidente fatal com um dos seus aviões. Suponha que todos os vôos sejam cancelados por seis meses, enquanto se aguarda o término de uma investigação. Imagine também que, quando os
MODELO DE DOMINIO: VISUALIZAÇAO DOS LONCEIIOS 101
vôos são cancelados, os seus correspondentes objetos de software Vôo sejam excluídos da memória do computador. Portanto, após o acidente, todos os objetos Vôo serão excluídos.
Se o único registro que mostra para qual aeroporto um vôo se destina estiver nas instâncias de Vôo, as quais representam vôos específicos para uma data e hora específicas, não existirá mais um registro sobre quais rotas de vôo a linha aérea tem.
Para resolver este problema, é necessária uma DescriçãoDeVôo (ou EspecficaçãoDe Vôo) que descreva um vôo e sua rota, mesmo quando um determinado vôo não estiver programado (ver Figura 10.8).
Observe que o exemplo precedente é sobre um serviço (um vôo), em vez de um bem (como um HambúrguerVegetariano). As descrições de serviços, ou planos de serviços, geralmente são necessárias.
Como outro exemplo, uma companhia de telefonia móvel vende pacotes como “bronze”, “ouro”, etc. E necessário ter o conceito de uma descrição do pacote (um tipo de plano de serviços que descreve tarifas por minuto, o conteúdo de Internet sem fio, etc.), separado do conceito de um pacote efetivamente vendido (como “pacote de ouro vendido para Craig Larman, em 1° de janeiro de 2002, a US$55 por mês”). O departamento de Marketing necessita definir e registrar este plano de serviço, ou Descri çãoDePacoteDeComunicaçõesMóveis, antes que algum seja vendido.
Voa-oara roi
1 nome
Pior
*
1
Melhor
Figura 10.8 Especificações sobre outras coísas.
Descrição de serviços
162 UTILIZANDO UML E PADRÕES
10.8 Notação UML, Modelos e Métodos: Perspectivas Múltiplas
O PU define algo chamado Modelo de Domínio, o qual é ilustrado com notação UML. Entretanto, não há um termo “Modelo de Domínio” na documentação oficial da UML. Isso aponta para uma importante percepção:
A UML simplesmente descreve tipos puros de diagramas, como diagramas de classes e de seqüência. Ela não superpõe um método ou uma perspectiva de modelagem a estes diagramas. Em oposição a isso, um processo (como o PU) aplica os diagramas puros da UML no contexto de modelos definidos por metodologistas.
Por exemplo, a notação de diagramas UML puros pode ser usada para criar imagens de classes conceituais do domínio (um modelo de domínio), classes de software, tabelas de banco de dados relacionais, etc.
Dessa forma, não confunda a notação dos diagramas básicos da UML com sua aplicação para visualizar vários tipos de modelos definidos por metodologistas (ver Figura 10.9). Esta observação se aplica não apenas aos diagramas de classes da UML, mas à maioria das notações UML.
Como outro exemplo de diagramas puros (metodologicamente neutros) que são interpretados de maneira diversa em diferentes modelos, temos os diagramas de seqüência da UML, que podem ser utilizados para ilustrar as mensagens entre objetos de software (como no PU) ou a interação entre pessoas e partes no mundo real (como no Modelo de Objetos de Negócio no PU).
Essa noção foi enfatizada no método orientado a objetos Syntropy [CD94] e reiterado por Martin Fowler em UML Distilled [FSOO], ou seja, a mesma notação diagramática pode ser usada por três tipos de perspectivas e modelos:
1. Perspectiva essencial ou conceitual - os diagramas são interpretados como uma descrição de coisas no mundo real ou domínio de interesse.
2. Perspectiva de especificação - os diagramas (com a mesma notação usada para modelos essenciais) são interpretados como uma descrição de abstrações de software ou componentes com especificações e interfaces, mas sem se comprometer com uma implementação em especial (por exemplo, não especificamente uma classe em C# ou Java).
3. Perspectiva de implementação - os diagramas (com a mesma notação usada para modelos essenciais) são interpretados como uma descrição de implementações
de software em uma tecnologia e linguagem específicas (como Java).
Superposição de terminologias: UML versus métodos
Na UML pura, as caixas retangulares mostradas na Figura 10.9 são chamadas de
classes, mas observe que na UML este termo abrange uma diversidade de fenôme
MODELO DE D0MINI0: VIsuAuzAÇÃo Dos CONCEITOS 163
_______________ Modelo do Domínio
Venda doPU
Pagamento - 1 -
1 Paga por A notaçao pura de
quantia data diagrama de classes
________________ hora da UMLéusada em
um modelo essencial
visualizando conceitos
do mundo real.
_______________ Modelo de Projeto
______________ do PU
Venda
Pagamento A notação pura de
1 1 data: Data diagrama de classes
quantia: Moeda Paga-por horaDeinício: Hora da UML é usada em
__________________ um modelo de imple mentaçã visualizando
obterSaldo ():Moeda obterTotal ():Moeda componentes de software.
Figura 10.9 A notação UML pura é aplicada em diferentes perspectivas e modelos definidos por um processo ou método.
nos - questões físicas, questões de software, eventos, etc.6 Um processo, ou método, superporá terminologias alternativas à UML. Por exemplo, no PU, quando as caixas da UML são desenhadas no Modelo de Domínio, elas podem ser chamadas de conceitos de domínio ou classes conceituais; o Modelo de Domínio oferece uma perspectiva conceitual. No PU, quando são desenhadas caixas UML no Modelo de Projeto, elas são oficialmente chamadas de classes de projeto; o Modelo de Projeto oferece uma perspectiva de especificação ou implementação, como o modelador desejar.
Independentemente da definição, o aspecto importante a observar é que é útil fazer a distinção entre as perspectivas de um analista de domínio, que procura classes conceituais do mundo real, como uma venda (uma perspectiva conceitual), e de um projetista de software, que especifica entidades de software, como uma classe de software Venda (uma especificação ou perspectiva de implementação).
A UML pode ser usada para ilustrar essas perspectivas com notação e terminologia bastante similares, de maneira que é importante ter em mente qual a perspectiva que está sendo utilizada (uma visão de análise, de projeto ou de implementação).
6Uma classe UML é um caso especial do elemento do modelo UML muito geral conhecido como classificador (classifier) - algo com características estruturais e/ou comportamento, incluindo classes, atores, interfaces e casos de uso.
1b4 UTILIZANDO UML E I’ADROES
Para evitar confusão, este livro usará termos relacionados com classes como
segue, uma maneira consistente tanto com a UML quanto com o PU:
• Classe conceitual - um conceito ou coisa do mundo real. Uma perspectiva conceitual ou essencial. O Modelo de Domínio do PU contém classes
conceituais.
• Classe de software - uma classe que representa uma perspectiva de especificação ou implementação de um componente de software, independentemente de processo ou método.
• Classe de projeto - um membro do modelo de projeto do PU. É um sinônimo de classe de software, mas, por alguma razão, desejo enfatizar que
ela é uma classe no Modelo de Projeto. O PU permite que uma classe de
projeto tenha perspectiva de especificação ou de implementação, conforme o modelador desejar.
• Classe de implementação - uma classe implementada em uma linguagem orientada a objetos, como Java.
• Classe - como na UML, o termo geral que representa ou uma coisa no mundo real (uma classe conceitual), ou de software (uma classe de software).
10.9 Diminuição do Hiato de Representação
Examine a Figura 10.10. Por que os livros e educadores que discutem um projeto orientado a objetos comum mostram somente o uso de classes de software cujos nomes refletem vocabulário comum do domínio? Por que escolher um nome de classe de software, como Venda, e o que uma Venda faz?
Simplesmente escolher nomes que reflitam o vocabulário do domínio (Venda) melhora a compreensão rápida e fornece uma indicação do que esperar do pedaço de código na classe de software Venda. Temos um modelo mental ou um modelo de domínio em questão (por exemplo, uma loja que vende coisas). No mundo real, sabemos que a venda tem uma data. Conseqüentemente, se criarmos uma classe Java de nome Venda, e dermos a ela a responsabilidade de saber sobre uma venda real e sua data, então a classe Java Venda corresponderá ao nosso modelo mental ou modelo de domínio do domínio real, ou seja, ela apelará para nossas “intuições” do domínio.
O Modelo de Domínio fornece um dicionário visual do vocabulário do domínio e conceitos nos quais obtemos inspiração para dar nome a certas coisas no projeto de software.
Isso está relacionado com o problema do hiato de representação ou hiato semântico
- o hiato entre nosso modelo mental do domínio e sua representação em software.
MODELO DE DOMíNIO: VISUAUZAÇÃO DOS CONCEITOS 165
Um Pagamento no Modelo de Domínio é um conceito, mas um Pagamento no Modelo de Projeto é uma classe de software. Eles não são a mesma coisa, mas a primeira inspirou a nomenclatura e definição da segunda.
Isso reduz o hiato de representação.
Essa é uma das grandes idéias na tecnologia de objetos.
Modelo de Domínio do PU Visão dos interessados dos conceitos do domínio dignos de nota.
Venda
data: Data horaDeinicio: Hora
obterTotal O: Moeda
Modelo de Projeto do PU
O desenvolvedor orientado a objetos se inspirou no domínio do mundo real ao criar as classes de software.
Portanto, o hiato de representação entre o modo como os proponentes e interessados no projeto concebem o domínio e sua representação em software foi reduzido.
Figura 10.10 No projeto e programação orientados a objetos, é comum criar classes de softwarecujos nomes e informações tenham sido inspirados pelo domínio do mundo real.
Em um extremo, poderíamos codificar diretamente a aplicação do PDV ProxGer em código binário puro para invocar o conjunto de instruções do processador. Compreendemos que o hiato de representação é vasto e que, portanto, haverá um custo real - embora difícil de quantificar - em um software que apresenta um hiato tão grande de representação; é difícil compreendê-lo e relacioná-lo com o domínio do problema. Próximas ao outro extremo deste espectro estão as tecnologias de objetos que nos permitem criar blocos de código agrupados em classes cujos nomes refletem o tipo de agrupamento que percebemos no mundo real. No mundo real, percebemos uma “parte” (ou evento) chamada venda; assim, no mundo do software, temos uma classe chamada Venda. Esse relacionamento um-para-um, mais próximo entre o vocabulário do domínio e o vocabulário do nosso software e seu agrupamento, reduz o hiato de representação. Isso acelera a compreensão do código existente (porque ele funciona da maneira que esperamos, conhecendo o domínio) e sugere modos “naturais” de estender o código para que este corresponda de maneira similar ao domínio, ou apele para nossas intuições do domínio. Dito simplesmente, o modelo do software nos lembra o modelo conceitual ou mental, funcionando de maneira previsível.
Existe uma vantagem prática para os modelos de software que reduzem o hiato
de representação. A maioria dos engenheiros de software sabe que isso é verdade, em-
- - - nomes no
inspira
objetos - - - -
e
166 UTILIZANDO UML E PADRÕES
bora seja de difícil quantificação. De fato, uma prova disso é que os desenvolvedores Java que querem dificultar a engenharia reversa do código-fonte, a partir do bytecode mudam os nomes das classes e dos métodos Java de forma que fiquem ininteligíveis, não apelando, assim, para o uso das nossas intuições do domínio, embora as estruturas de controle e de dados permaneçam inalteradas.
Naturalmente, a tecnologia de objetos também tem valor porque pode dar suporte ao projeto de sistemas elegantes, fracamente acoplados, fáceis de escalar e estender, como será explorado no restante do livro. Um hiato de representação é útil, mas inquestionavelmente secundário diante da vantagem da tecnologia de objetos de dar suporte à facilidade de mudanças e extensões e do suporte que ela oferece para administrar e ocultar a complexidade.
10.10 Exemplo: o Modelo de Domínio para o PDV ProxGer
A lista de classes conceituais gerada para o domínio do PDV ProxGer pode ser representada graficamente (ver Figura 10.11) para mostrar a gênese do Modelo de Domínio.
Registro tem Loja Venda
LinhaDeltem Caixa Cliente Gerente
Pa amento Catálogo Especificação
g DeProdutos DeProduto
Figura 10.11 Modelo de domínio inicial.
Os atributos e as associações para o modelo conceitual serão considerados nos capítulos subseqüentes.
10.11 Modelos de Domínio no PU
Como sugerido no exemplo da Tabela 10.2, um Modelo de Domínio geralmente é iniciado e completado na elaboração.
Concepção
Os modelos de domínio não encontram uma forte motivação na concepção, uma vez que a finalidade desta não é uma investigação séria, mas decidir se o projeto merece uma investigação mais profunda na fase de elaboração.
IV1OVtLO Uh UOMINIO VISUALILAÇAU VOS LONCt1 lOS 113/
Tabela 10.2 Amostra de artefatos do PU e sua seqüência temporal
- iniciar; r - refinar
Elaboração
O Modelo de Domínio é criado principalmente durante as iterações da elaboração, quando é maior a necessidade de compreender os conceitos dignos de nota e mapear alguns para classes de software durante o trabalho de projeto.
Embora, ironicamente, um número significativo de páginas seja dedicado a explicar a modelagem de objetos do domínio, em mãos experientes, o desenvolvimento de um modelo de domínio (parcial, e que cresce de modo incremental) em cada iteração deveria tomar poucas horas. Essas são ainda mais abreviadas pelo uso de padrões de análise predefinidos.
O modelo de objetos de negócio do PU versus o modelo de domínio
O Modelo de Domínio do PU é uma variante oficial do Modelo de Objetos de Negócio do PU (MON) menos comum. O MON do PU - não confundir com o que outras pessoas e métodos podem definir como MON, o qual é um termo amplamente empregado com diferentes significados - é um tipo de modelo da empresa usado para descrever todo o negócio. Ele pode ser usado quando fazemos engenharia de processos de negócio ou reengenharia, independentemente de qualquer aplicação de software (como é o PDV ProxGer).
Disciplina Artefato Iteração- Concepção Cl Elaboração El..En Construção Ctl...Ctn Transição Tt...T2
Modelagem de Negócio Modelo de Domínio
Requisitos Modelo de Casos de Uso (DSS5) r
Visão r
Especificações Suplementares i r
Glossário i r
Projeto Modelo de Projeto i r
Documento de Arquitetura de software i
Modelo de Dados i r
Implementação Modelo de Implementação i r r
Gestão de Projeto Plano de Desenvol viment de software i r r r
Teste Modelo de Teste i r
Ambiente Pasta de Desenvolvimento i r
168 UTiLIZANDO UML E 1ADROES
[O MON do PUJ serve como uma abstração do modo como os funcionários do negócio e as entidades de negócio precisam ser relacionados e colaborar para tocar o negócio [RUP].
O MON é representado com diversos diagramas (classe, atividade e seqüência) que ilustram como a empresa funciona (ou deveria funcionar). Ele será mais útil se estivermos executando uma engenharia de processos que abranja toda a empresa, mas é uma atividade menos comum do que criar uma simples aplicação de software isolada.
Conseqüentemente, o PU define o Modelo de Domínio como o artefato de sub- conjunto mais freqüentemente criado ou como uma especialização do MON.
Você pode optar por desenvolver um modelo de objetos de negócio “incompleto”, focando a explicação das “coisas” e produtos importantes para um domínio. ... Isso geralmente é chamado de modelo de
domínio [RUPI.
10.12 Leituras Adicionais
O livro de Odeli, Object-Oriented Methods: A Foundation, fornece uma introdução sólida à modelagem conceitual do domínio, O livro de Cook e Daniel, Designing Object Systems, também é útil.
O livro de Fowler, Analysis Patterns, oferece padrões que vale a pena usar em modelos de domínio e, definitivamente, é recomendado. Um outro bom livro que descreve padrões em modelos de domínio é o de Hay, Data Model Patterns: Conventions of Thought. O conselho e a orientação de especialistas em modelagem de dados que compreendem a distinção entre modelos conceituais puros e modelos de esquemas de bancos de dados podem ser muito úteis para a modelagem de objetos do domínio.
Java Modeling in Color with IJML [CDL99] tem mais conselhos e orientação relevantes para a modelagem de domínio do que o título sugere. Os autores identificam padrões comuns em tipos relacionados e suas associações; o papel do uso da cor é realmente uma visualização de categorias comuns destes tipos, como descrições (azul), papéis (amarelo) e intervalos de tempo (rosa). A cor é usada como auxílio na visualização dos padrões.
Desde o trabalho original de Abbott, a análise lingüística tem adquirido técnicas mais sofisticadas para a análise orientada a objetos, geralmente chamada de modelagem de linguagem natural, ou uma variação. Ver [Moreno97] como exemplo.
10.13 Artefatos do PU
MODELO DE L)OMINIO: VISUALIZAÇÃO DOS CONCEITOS 169
Plano de Desenvolvimento de Software
Plano
de Teste
Teste iiii
Pasta de Desenvolvimento
Ambiente
A influência dos artefatos, enfatizando o Modelo de Domínio, é mostrada na Figura
10.12.
Modelagem de Negócio
Amostras de Artefatos do PU
termos, conceitos,
atributos,
associações
Requisitos
Projeto
elaboração de alguns termos no modelo de domínio
Glossário
Documento de Arquitetura de Software
Gestão de Projeto
As classes de software na camada do domínio do projeto se inspiram nos nomes, atributos e associações no modelo de domínio.
Figura 10.12 Amostra da influência dos artefatos do PU.
Ir
11
Modelo de Domínio:
Inclusão de Associações
OBJETIVOS
• Identificar associações para um modelo de domínio.
• Distinguir entre as associações “que devem ser conhecidas” daquelas somente capazes de auxiliar na compreensão.
Introdução
É importante distinguir as associações de classes conceituais necessárias à satisfação dos requisitos de informação dos cenários em desenvolvimento daquelas que auxiliam na compreensão do modelo de domínio. Este capítulo explora a identificação de associações adequadas e acrescenta associações ao modelo de domínio para o estudo de caso ProxGer.
11.1 Associações
Uma associação é um relacionamento entre tipos (ou, mais especificamente, entre instâncias desses tipos) que indica uma conexão com significado e interesse (ver Figura 11.1).
172
UTILIZANDO 1JML E 1ADROES
Na UML, as associações são descritas como “um relacionamento semântico e:
tre dois ou mais classificadores que envolve conexão entre suas instâncias”.
ssociação h1
_________ o__________
r Registra-a-corrente
Registro 1 1 Venda
Figura 11.1 Associações.
Critérios para associações úteis
As associações dignas de nota exigem o conhecimento de um relacionamento que necessita ser preservado por algum tempo - que pode ser de milissegundos ou de anos, dependendo do contexto. Em outras palavras, entre quais objetos necessitamos ter uma memória de um relacionamento? Por exemplo, precisamos lembrar quais instâncias de LinhaDeltemDe Venda são associadas a uma instância de Venda? Sim, caso contrário não seria possível reconstruir a venda, imprimir um recibo ou calcular um total de vendas.
Considere a inclusão das seguintes associações em um modelo de domínio:
.
Associações para as
...