CASO DE ESTUDO AULA4 LINGUAGEM UNIFICADA

Prévia do material em texto

x
RODRIGO OLIVEIRA SPíNOLA, MARCO ANTÔNIO PEREIRA ARAÚJO
·UML na Prática
Construindo Diagramas de Classes
ROORIGO OLIVEIRA SPíNOLA
(rodrigoêsqlmagazine.cem.bn é Editor
Chefe das revistas SQL Magazine e
WebMobile. É bacharel em Ciências da
Computação pela Universidade Salvador
(UNIFACS) e Mestre em Engenharia de'
Sistemas e Computação pela COPPEjUFRJ
na linha de Engenharia de Software onde
atualmente cursa o Doutorado, sendo membro do grupo ESE
(Engenharia de Software Experimental). É implementador MPS
BR, membro da \I COPPE.Suas áreas de interesse são: processos
de software, engenharia. de software orientada a objetos,
métricas e complexidade de software, inspeções de software,
ambientes de désenvolvimento de software, engenharia de
requisitos, integração de ferramentas, engenharia de software
experimental e ubiqüidade computacional.
44 SQLMagazine UML na Prátiea- Construindo Diagramas de Classes
E
xistem diversos pontos críticos causadores
de inserção de defeitos durante odesenvol-
vimento 'de um software. Podemos citar re-
I
quisitos, projeto e codificação como alguns
- exemplos. Somados a estes pontos críticos,
tem-se um qu#o- momento do. desenvolvimento que me-
rece uma aténção especial: a/elaboração da soluçã<;>para o
problema através do diagrama de classes. Elaborar de for-
ma criteriosa diagramas de-classes é um fator de sucesso
de projetos de software por que, além do fato de ser um
momento propenso à inserção de defeitos no software, são
neles em que são transformados os problemas do usuá-
rio em uma solução computacional, servindo como uma
ponte entre requisitos e codificação. Se esta ponte for mal
projetada, o software também será (ver Figura 1).
A UML (Unified Modeling Language) apresenta uma
série de diagramas parq a modelagem de sistemas orien-
tados a objetos. Os diagramas mais comuns são o diagra-
ma de casos de uso (representa as funcionalidades de um
sistema), o diagrama de classes (ler Nota 1) (descreve as
classes do modelo numa visão estática), o diagrama de
seqüência, ou seu substituto na UML 2.0, o diagrama de
comunicação (descrevem as funcionalidades através de
uma visão dinâmica) e o diagrama de estados (apresenta o
comportamento dinâmico de um objeto).
O objetivo desta matéria é trazer ao leitor algumas boas
práticas para elaboração de diagramas de classes, através
de sua aplicação prática em dois estudos de caso.
Modelagem de classes
Existem diferentes caminhos para se chegar ao diagra-
ma de classes. Dois dos mais utilizados são:
Especificar os casos de uso e, então, partir para o
diagrama de classes: neste caso, as classes, seus atri-
butos, relacionamentos e métodos são identificados
Inserindo defeitos ao longo do desenvolvimento
r.
Figura 1. Inserindo defeitos no projeto.
diretamente a partir dos requisitos de software de-
finidos. Pode-se utilizar, em seguida, o diagrama de
seqüência para verificar se os relacionamentos e mé-
todos definidos fazem sentido.
• Especificar os casos de uso, elaborar o diagrama de
seqüência e, então, partir para a construção do dia-
grama de classes: neste caso, a construção do dia-
grama de seqüência ajudará na identificação das
classes, relacionamentos e métodos a partir da es-
pecificação de requisitos. É uma abordagem muito
interessante também.
Não existe um caminho mais correto que o outro, de-
vendo o desenvolvedor utilizar aquele que se sentir mais a
vontade em seguir. Neste artigo será trabalhada a primei-
ra opção: caso de uso ® diagrama de classes, que é a forma
mais natural de ser utilizada. Neste caso, partiremos para a
construção do diagrama de classes atentando para a identi- _
ficação de quatro elementos: entidades (classes) do software,
seus atributos, suas operações e o relacionamento entre as
classes. Assim, um processo para criação de um modelo de
classes pode ser dividido em quatro etapas (ver Figura 2).
Etapa 1: Identificação de entidades (classes)
Classes permitem que sejam representados no mundo
computacional elementos do mundo real, ou seja, do pro-
blema para o qual o software está sendo desenvolvido. Elas
permitem descrever um conjunto de objetos que compar-
tilhem os mesmos atributos, operações, relacionamentos e
semântica, e representam o principal bloco de construção
de um software orientado a objetos.
Seguindo nossa abordagem para a construção do diagra-
ma de classes (partindo da especificação dos casos de uso),
para identificá-Ias, procura-se na especificação por concei-
tos que representem objetos do domínio da aplicação a ser
desenvolvida. A Figura 3 apresenta a simbologia para uma
classe chamada ContaBancaria utilizando a UML.
Etapa 2: Identificação de atributos
Com as classes definidas, precisam-se especificar quais
são seus atributos. Estes são as propriedades que caracteri-
""""""'.-...........,.
~
~ --
UML na Prática" Construindo Diagramas de Classes Ano 3 34a Edição 45
Figura 2. Elaborando uma solução computacional.
Nota 1. Diagrama de classes
De forma simplificada. um diagrama de classes descreve os
"tipos" de objetos do software e os vários tipos de relacionamentos
estáticos que existem entre eles. De todos os diagramas da UML.
este é o diagrama mais comumente utilizado pelas empresas.
zam um objeto. Por exemplo, uma entidade conta bancária
possui como atributos o número e o saldo. É bastante sim-
ples identifi~~r os atributos de' cada classe, basta identificar
as características que descrevam sua classe no domínio do
problema em questão. Note que os atributos identificados
devem! estar alinhados com as necessidades do usuário
para o problema.
A Figura 4 apresenta a classe ContaBancaria com alguns
de seus atributos. É importante observar o sinal" _" à es-
querda do nome dos atributos. Isto indica que os mesmos
são privados, encapsulados, proibindo que seu conteúdo
seja manipulado por operações que não sejam da própria
classe. Isso proporciona maior independência da classe,
aumentando sua possibilidade de reutilização. Ainda te-
mos mais dois sinais: "+" e "#". O sinal "+" indica que
um atributo é público (ou seja, este pode ser acessado por
qualquer outro objeto) e o sinal "#" indica um atributo
protegido, podendo ser herdado por subclasses.
Etapa 3: Identificação de operações
Identificadas as classes e seus atributos, o próximo pas-
so é a identificação das operações de cada classe, também
ICodaBancaria l
Figura 3. Classe ContaBancaria.
ContaBancaria
-Numero
-Saldo
Figura 4. Classe ContaBancaria com seus atributos.
chamadas de métodos ou serviços. Fazendo um paralelo
com objetos do mundo real, operaçoes são ações que o
objeto é capaz de efetuar. Dessa forma, ao procurar por
operações, devem-se identificar ações que o objeto de uma
classe é responsável por desempenhar dentro do escopo
do sistema que será desenvolvido. A Figura 5 apresenta
algumas operações da classe ContaBanc"aria. Ao contrário
" dos atributos, normalmente operações são públicas, per-
mitindo sua utilização por outras classes e objetos.
. Etapa 4: Identificação de relacionamentos
O último passo a ser executado na construção de um
diagrama de classes é a definição dos relacionamentos en-
tre as classes do modelo. Para isso, deve-se entender um
pouco sobre os tipos de relacionamentos que podem apa-
recer entre classes em um diagrama de classes. Os tipos de
relacionamento mais utilizados são:
• Generalização (Herança): denota relações "é um
tipo de", onde subclasses são especializações de
superclasses e herdam seus atributos e operações.
O segredo na identificação correta deste tipo de
relacionamento está na semântica "é um tipo de".
Isto porque as pessoas, muitas vezes, utilizam o re-
lacionamento de herança como um mecanismo de
reutilização esquecendo-se da semântica associada
ao relacionamento. Não é porque Cliente e Agência
possuem algum atributo em comum, como nome,
que devam herdar de uma superclasse chamada
"Cliente_Agência". Percebe-se que esta entidade
não faz sentido algum.
Na Figura 6 tem-se um exemplo de generalização
definindo as classes Conta Corrente e ContaPoupan-
ca comosubclasses de ContaBancaria. .
Associação: representa uma relação estrutural entre
duas classes indicando que estas se comunicam atra-
vés de troca de mensagens. É representada por uma
linha simples ligando duas classes (ver Figura 7) e
pode conter atributos como nome, multiplicidade e
navegabilidade. O nome representa a semântica do
relacionamento indicando o porquê das classes esta-
rem relacionadas; a multiplicidade indica a quantos
objetos de uma determinada classe um objeto pode
se comunicar; e a navegabilidade especifica quem
enxerga quem no relacionamento, ou seja; se um
objeto tem conhecimento da existência de outro.
Por exemplo, a Figura 7 informa o seguinte:
o um objeto da classe ContaBancaria está
associado a nenhum ou vários objetos da
classe Cliente (no caso de conta conjunta).
Essa informação é transmitida através do
indicador de multiplicidade (O .. *) mais pró-
ximo à classe Cliente;
o um objeto da classe Cliente pode estar asso-
ciado a nenhum ou vários objetos da classe
46 SQLMagazine UML na Prática - Constl1lindo Diagramas de Classes
ContaBancaria. Essa informação é transmi-
tida através do indicador de multiplicidade
(O .. *) mais próximo à classe ContaBancaria;
•
Auto-Associação: uma classe ainda pode associar-se
com ela mesma, caracterizando uma auto-associa-
ção. A Figura 8 apresenta uma auto-associação na
classe ContaBancaria, representando que uma con-
ta pode estar associada a uma conta investimento,
que nada mais é do que uma outra conta bancária.
Agregação: é uma associação cuja semântica é "par-
te de". Neste tipo de relacionamento, tem-se uma
classe representando o todo e outras classes, suas
partes. Por exemplo, uma ContaBancaria é parte in-
tegrante de uma Agência, inclusive uma conta ban-
cária é identificada pelo número da agência e pelo
número da conta (ver Figura 9). Esta figura ainda indi-
ca que um objeto da classe Agencia está relacionado a
vários objetos da classe ContaBancaria, enquanto que
um objeto da classe ContaBancaria está relacionado a
um único objeto da classe Agencia. Uma agregação é
representada por uma linha simples com um losango
sem preenchimento do la,do do todo.
Composição: é uma associação que expressa a se-
mântica "parte de" mais "fortemente". Neste caso,
/,,:'
CortaB ancari a
-Numero
-Saldo
+E fetuarSaqueO
+E fetuarD epositoO
+EmitirSaldoO
+E mitirEldratoO
.I
Figura 5. Classe Conta Bancaria com seus atributos e operações.
ComBancalia
t>-
I ComCorreme ComPoupanca I
I I
-FIgura 6. Generalização de classes.
I C_.ncaria I O..' Cliente
O.!
Figura 7. Associação entre classes.
CortaB ancari a 0 ..1
-
Contal n vestim ento .
0 ..1 I'---------'
Figura 8. Auto-associação em uma classe.
---- -- -----------------------------------------
I.
I
I
se o objeto que representa o todo for destruído, suas
partes obrigatoriamente também serão. Por exem-
plo, quando se destrói uma ContaBancaria, todas as
suas Movimentações também precisam ser destruí-
das (ver Figura 10). Além disso, uma composição in-
dica que, para acessar os métodos de uma classe que
represente a "parte", deve-se primeiro interagir com
a classe que representa o "todo". É a classe "todo"
quem interage com suas classes" parte". Uma com-
posição é representada por uma linha simples co~
um losango preenchido do lado do todo.
Navegação: representa se um objeto possui uma re-
ferência para um outro numa associação. A maioria
das ferramentas CASE para modelagem 00 assu-
me que o padrão de associações é possuir navega-
. bilidade bidirecional, ou seja, objetos de uma classe
possuem referências para os objetos da classe asso-
ciada, e vice-versa. Entretanto, muitas vezes torna-
se interessante restringir a navegabilidade, seja por
diminuir o esforço de desenvolvimento, seja por re-
almente não ser necessária a comunicação entre ob-
jetos num determinado sentido. A Figura 11 exibe
uma navegação da classe Movimentacao (de Contas
Bancárias) para a classe Tipolvlovimentacao. Isso in-
dica que a classe Movimentacao "conhece" a classe
TipoMovimentacao e pode interagircom ela. O con-
trário não é verdade. Neste exemplo, pode não fa-
zer sentido dado um tipo de movimentação (trans-
ferência, por exemplo), saber quais movimentações
que aconteceram para este tipo, em todas as contas.
O sinal do "X" não é padrão em todas as ferramen-
tas CASE. Restrições de navegabilidade podem ser
feitas em associações, agregações e composições ..
Para identificar se uma navegabilidade é necessária
ou não, uma boa possibilidade é analisar o conjun-
to de diagramas de seqüência do sistema, caso estes
existam. Desta forma, navegabilidades podem ser
definidas num segundo momento, quando do refi-
namento do diagrama de classes, após a construção
dos diagramas de seqüência.
•
I
I
I
l
I
I.
I
~
~
I
!
t
Por exemplo, a Figura 11 informa o seguinte:
o um objeto da classe Movimentacao sabe a
qual objeto da classe TipoMovimentacao
estará se comunicando. Essa informação
é transmitida através do indicador de na-
vegabilidade (a seta). Em código, isso sig-
nifica que a partir de um objeto da classe
Movimentacao tem-se acesso a um objeto
da classe TipoMovimentacao, ou seja, exis-
te na classe algum atributo que seja do tipo
TipoMovimentacao;
o um objeto da classe TipoMovimentacao
não' sabe que objeto da classe Movimen-
tacao está utilizando. Essa informação é
transmitida através do indicador de nave-
gabilidade (o símbolo "X", ou a falta dele
numa associação unidirecional). Em códi-
go, isso significa que a partir de um objeto
da classe TipoMovilnentacao não se conse-
gue referenciar diretamente um objeto da
classe Movimentacao.
• Classe associativa: representa situações onde de-
terminados atributos não podem ser colocados em
nenhuma das classes participantes de uma associa-
ção, por conter informações referentes exclusivas
à ligação dos objetos das duas classes. A Figura 12
demonstra que a Validade e Senha de um cartão são
diferentes para cada um dos clientes de uma mes-
ma conta. Ou seja, dado um objeto Cliente associa-
do com um objetoContaBancaria, tem-se um objeto
Cartao com informações diferentes.
lio--~---- -- -----
UML na Prática - Construindo Diagramas de Classes Ano 3 34a Edição 47
Estudo de caso 1
Para o primeiro estudo de caso deste artigo, será consi-
derado um fragmento de um Sistema de Controle Bancá-
rio. Para este sistema, o gerente deve cadastrar agências,
clientes e abrir e fechar contas bancárias. Um cliente pos-
sui nome, endereço e telefone. Um cliente pode abrir vá-
. I
rias contas e ú;n.a)::onta pode ser de vários clientes, para o
"/ "
A.oná. fd O..' :1 C•••••••• ori. 1
Figura 9.: Agregação entre classes.
Movirnentac ao
1
CortaBancaria 1...•.. 1 I-Valor
. O.." -Data
Figura 10. Composição entre classes.
Movi rnenta c ao O .. " TipoMovimentacao
-Valor .i ..•.. -Descricao
-Dsta I'" '1 ...--O ebito _Credito
Figura 11. Navegabilidade entre classes
===c:'::..:i_ent::e:~~il-.:::O:.:.," __ O_.._._I C••••••••••••
Cartao
-Validade
-Senha
Figura 12. Classe associativa.
caso de contas conjuntas. Contas são de uma determinada
agência (que possui nome e númerp), além de poderem
estar vinculadas a uma conta de investimento, que nada
mais é que uma outra conta bancária. Contas ainda devem
possuir um número (formado pelo número da agência e
pelo número da própria conta) e saldo disponível, poden-
do ser corrente normal, corrente especial e poupança. Para
" contas poupança, devem-se armazenar os dias de venci-
mento e, para contas corrente especiais, informar o limite
de crédito. Contas ainda possuem movimentações de sa-
qu~ e depósito, que devem ter data e valor, além do tipo de
movimento, que pode ser débito ou crédito. Clientes ainda
podem solicitar cartões de contas bancárias, que devem ter
número, validade e senha para cada cliente, além de talões
de cheques para contas correntes, que devem armazenar o
número inicial e final das folhas. do talão. O sistema ainda
deve permitir aos clientes consultar saldos e extratos.
O diagrama de casos de uso da Figura 13 apresenta as
principaisfuncionalidades do sistema.
No diagrama de casos de uso da Figura 13, observa-se
que foram apresentadas as principais funcionalidades do
sistema, associadas aos atores que as utilizam. Percebe-se
que um ator é quem realmente interage com o sistema.
Vale destacar aqui que ao definirmos um diagrama de
casos de uso, o mais importante não é o diagrama em si,
mas sua especificação. Por questão de espaço, será apre-
sentada a especificação de apenas um dos casos de uso
apresentados no diagrama da Figura 13. Observa-se na
Tabela 1 o fluxo de ações envolvido no caso de uso Ca-
dastrar Cliente.
Seguindo o processo anteriormente definido, a Etapa 1
(Identificação de Classes), objetiva encontrar as classesdo
modelo. Neste estudo de caso, as entidades encontradas
foram Agência, Conta, Conta Corrente, Conta Corrente Nor-
mal, Conta Corrente Especial, Conta Poupança, Movimenta-
ção, Tipo de Movimentação, Talão de Cheques e Cartão de
Conta, representando elementos do domínio da aplicação.
É importante atentar para a entidade Gerente. O fato
dela representar um ator do sistema não significa neces-
sariamente que deverá estar contemplada no diagrama de
classes. Então, como se pode definir se um ator participará
ou não de um diagrama de classes? Basta atentar para o
fato de haver a necessidade de manter algum atributo e/ou
realizar alguma operação sobre ele. Neste estudo de caso,
o Gerente não será uma classe, pois essas necessidades
não estão presentes.
A próxima etapa refere-se à identificação dos atributos
das classes. A Tabela 2 descreve os atributos identificados
a partir dos requisitos inicialmente definidos. Observa-se
que rtão estão descritos os atributos de ligação entre as
classes. Isso é papel dos relacionamentos.
A etapa seguinte refere-se à identificação das operações
das classes. A Tabela 3 resume esta etapa apresentando
as principais operações das classes do modelo. É impor-
tante ressaltar que muitas vezes a identificação das opera-
48 SQLMagazine UML na Prática - Construindo Diagramas de Classes
'RI
?
Eenacy-* E~
ec,me'(c~~
~
e>-*-+~I~
Gerentee
Figura 13. Diagrama de casos de uso.
ções pode ser feita posteriormente, ao refinar o diagrama
de classes. Uma boa ferramenta da UML para detalhar o
comportamento de casos de uso numa visão orientada a
objetos e, consequentemente, auxiliar na descoberta das
operações, é o diagrama de seqüência.
O último passo refere-se à identificação dos relaciona-
mentos e, para isso, efetua-se a análise dos casos de uso
de forma a encontrar estas relações entre as classes já
identificadas:
• Generalização: verifica-se se há alguma relação "é
um tipo de" entre as classes identificadas. Neste es-
tudo de caso, ContaCorrente e ContaPoupanca "são
tipos de" ContaBancaria, enquanto Conta Corrente-
Especial" é um tipo de" ContaCorrente.
• Associação: verifica-se se há a necessidade de um
objeto de uma classe utilizar serviços disponibiliza-
dos por }:ll!l objeto de outra classe ou, simplesmen-
te, "córl'hécer" o outropbjeto. Neste estudo de caso,
tem-se que uma conta bancária está relacionada
com um ou mais clientes e um cliente pode possuir
mais de uma conta bancária. Insere-se então uma
'associação entre estas classes. Existe uma segunda
associação entre Movimentacao e TipoMovimenta-
cao, onde uma movimentação é de um único tipo
de movimentação e um tipo de movimentação pode
estar relacionado a diversas movimentações. Verifi-
ca-se ainda uma terceira associação entre as classes
ContaCorrente e TalaoCheques, onde uma conta
corrente pode possuir vários talões de cheques e
um talão de cheques é de uma única conta corrente.
Esta associação não poderia ter sido feita na classe
ContaBancaria uma vez que uma conta poupança
não possui talões de cheques.
• Auto-Associação: verifica-se se existe alguma classe
que necessita ser relacionada a ela mesma. Neste estu-
do de caso; existe uma auto-associação na classe Con-
taBancaria, representando uma conta de investimen-
tos, que nada mais é que uma outra conta bancária.
• Agregação: verifica-se se há alguma relação "parte
de". entre as classes identificadas. Neste estudo de
caso, tem-se que uma agência (o todo) é composta
de diversas contas bancárias (as partes). Percebe-se
ainda que a identificação da conta bancária é feita
pelo número da agência, acrescido do número da
própria conta bancária. Daí, modela-se este relacio-
namento através de uma agregação.
Este caso de uJio permite o cadastro (inclusão) de clientes do banco.
Cadastrar Cliente
Gerente
o caso de uso é iniciado quando o Gerente
seleciona a opção Cadastrar Cliente.
Sistema apresenta janela com os campos nome, endereço e
telefone.
Gerente preenche campos e selecioça a
opção Efetuar Cadastro.
Sistema valida as informações preenchidas pelo gerente (EX01).
Os campos devem estar todos preenchidos e de acordo com o domínio (tipo) do atributo. Se houver
problemas no preenchimento do formulário o sistema exibe a mensagem de erro: "Existem dados
inválidos no formulário ou algum campo não foi preenchido".
Caso o cliente já se encontre cadastrado, a mensagem "Este cliente já possui cadastro" é
apresentada.
Sistema cadastra cliente (EX02) e volta para a tela inicial. Neste
momento, este caso de uso é encerrado.
Tabela 1. Descrição do caso de uso Cadastrar Cliente.
Classe Atributos
Agencia Nome Numero
Conta Bancaria Numero Saldo
, ContaCorrenteEspecial LimiteCredito
ContaPoupanca DiasVencimento
Nome
Cliente Endereço
Telefone
Numero
Cartão Validade
Senha
Movimentacao
Data
Valor
TipoMovimentacao
Descricao
Debito_Credito
Tabela 2. Identificação dos atributos das classes.
Composição: verifica-se se há alguma relação "parte
de" forte entre as classes identificadas. Neste estudo
de caso identifica-se um relacionamento deste tipo
entre as classes ContaBancaria e Movimentacao,
uma vez que as movimentações são como atributos
.internos de contas bancárias. Além disso, a exclusão
de 'uma conta bancária necessariamente implica na
exclusão de suas movimentações. Neste caso, mode-
la-se esta situação através de uma composição.
• Navegação: verifica-se se existem "navegações" des-
necessárias entre classes. Neste estudo de caso, na
associação entre as classes Movimentacao e Tipo-
Movimentacao, utilizou a navegabilidade no senti-
do Movimentacao ® TipoMovimentacao, uma vez
que esta última não precisa utilizar nenhuma das
operações definidas na classe Movimentacao.
Classe Operações
EfetuarSaque
Efetuarüepostto
Conta Bancaria EmitirSaldo
/' EmitirExtrato
?'" -'"
" /. policitarCartao
Conta Corrente SolicitarTalao
Cartão
,,'(IalidarSenha
Verif
Movimentacao EfetuarMovimentacao
Tabela 3. Identificação das operações.
Classe Associativa: verifica-se se existem informa-
ções que precisam estar vinculadas à associação de
dois objetos (mas não a um deles em particular).
Neste estudo de caso, o número, validade e senha
de cartões de contas bancárias são diferentes para
cada um dos clientes de uma mesma conta bancária.
Modela-se esta situação utilizando-se uma classe
associativa.
Feito isto, chega-se à versão final do diagrama de classes
proposto pelo estudo de caso, que ,pode ser visto na Figu-
ra 14. Um refinamento deste diagrama ainda precisa ser
feito, definindo tipos de atributos e assinaturas das opera-
ções, com seus eventuais parâmetros de entrada e tipos de
retorno para o caso de funções.
Percebe-se na versão final do diagrama da Figura 14 que
a classe ContaBancaria tornou-se abstrata. Em,UML isso é
representado pelo nome da classe em itálico. Uma classe
abstrata não instancia objetos e é criada com a finalida-
de de agrupar atributos, métodos e/ou relacionamentos
comuns a outras classes. Não se deve achar que toda su-
UML na Prática - Construindo Diagramas de Classes Ano 3 34a Edição 49
Cliente
-Nome
-Endere6'Õ"
-Telefõne
CarUo
-Numero
o ..' -Vãlidade
-Senha-------
.•Vali darSenhaD
Agencia 1 O ..' +VeriftcarVelidade O
-Nome C CotrtilBlMcali.
-Numero
O .. ' -Numero
-Saldo .-:' MovimeIdIIc:ao
+E fetuarDeposRo() - O ..' -Valor
+E fetuarSaqueO-Data..•.
+EmftirSaldoO +E fetuarM ovim entacaoO
0 ..1 +E mftir!llclrato()r- +SoliátarCartaoO O ..'
Contal n vestim ento
0 ..11 \1
1 •~
TipoMouimentJlcao
ra'aoCheCJJes
COIÚCorrerte I I COIÚPaupan:a I -Descricao
-Numerolnicial O . .'
-NumeroFinal 1 +SoliátarTalao() I-DiasVencimento I
-Debfto_Credito
?
L COIÚCorrerteE 8pecia' I
I-LimiteCredRo
I
Figura 14. Diagrama de classes.
seu número de matrícula, e devem conter
ainda nome, endereço, telefone e depen-
dentes (com nome e data de nascimento),
além de estar associado, obrigatoriamen-
te, a uma filial. Tipo de Veículo apresenta
uma descrição (como caminhão e moto)
e o peso máximo que pode transportar,
além de estar associado a veículos. Cida-
des contêm o nome da cidade e o estado
a que pertence, representando as cidades
abrangidas pela empresa de transporte .
Distâncias envolvem as cidades origem .e
destino e, para cada par de cidades aten-
didas, deve haver a distância em quilô-
metros entre elas. Categoria do frete deve
conter descrição e um percentual, que
deve incidir sobre o valor do frete onde,
por exemplo, entregas rápidas têm au-
mento de 10%, entregas super-rápidas
têm aumento de 30%, e entrega normal
não tem acréscimo no valor. Cada Frete
tem um código, um cliente, o veículo que
deve efetuar o frete, cidade origem e ci-
dade destino, funcionário responsável e
_ itens a serem ,transportados, não podendo
- .: haver um frete sem os dados citados. Cada,.-'. ,
~ . frete deve te! ainda o seu valor, que deve
ser calculado através da distância entre as
cidades envolvidas e da categoria do fre-
te. Para isso, deve existir um valor padrão
para o km rodado. Um Item de Transporte
é cada objeto a ser transportado num frete
e deve possuir apenas uma descrição e seu
peso. Por fim, temos que o sistema ainda
deve emitir Nota Fiscal com todas as infor-
mações de um determinado frete, logo após
seu cadastramento.
A Figura 15 apresenta o diagrama de
casos de uso com as principais funcionali-
dades deste sistema.
No diagrama de casos de uso da Figura 15, observa-se
que, como é o funcionário quem utiliza todas as funções
do sistema, todos os casos de uso estão ligados a ele. Outra
característica é relativa ao caso de uso EmitirNotaFiscal.
Como este caso de uso é disparado sempre que um fre-
te for cadastrado, representa-se esta situação utilizando
uma seta com o estereótipo" < < Include >»", indicando
que o caso de uso CadastrarFrete dispara o caso de uso
EmitirNotaFiscal. Este tipo de situação é utilizado quando
se deseja destacar uma funcionalidade do sistema, como
neste caso, ou quando uma determinada funcionalidade
é utilizada por mais de um caso de uso, evitando que seja
descrita mais de uma vez.
Mais uma vez, destaca-se a importância em especificar
cada um dos casos de uso presentes no diagrama de casos
~*E ~ FundonarioCadastrarCategOri~ I
Figura 15. Diagrama de casos de uso.
perclasse é abstrata. Por exemplo, a classe Conta Corrente
é concreta, podendo instanciar objetos. Caso seja aberta
uma conta corrente comum, esta é instanciada a partir
desta classe.
Estudo de caso 2
o segundo estudo de caso considera um fragmento de
um sistema para uma Transportadora. Para este sistema, os
funcionários da transportadora devem cadastrar Clientes,
Filiais, Veículos, Funcionários, Tipos de Veículos, Cidades,
Distâncias, Categorias de Frete e Fretes de Clientes.
Clientes são pessoas físicas e possuem nome, endereço e
telefone. Filiais têm nome, endereço, telefone, funcionário
responsável e vários veículos. Veículos devem possuir nú-
mero de placa e um tipo de veículo, além de ser necessa-
riamente de uma filial. Funcionários são identificados pelo
50 SQLMagazine UML na Prática- Construindo Diagramas de Classes
x
Cadastrar Veículo
Este caso de uso.permite o cadastro (inclusão) de veículos da Transportadora.
o caso de uso é iniciado quando o Funcionário
seleciona a opção Cadastrar Veículo.
Sistemá apresenta janela com os campos número da placa, tipo
de veículo e filial.
Funcionário preenche campos e seleciona a
opção Efetuar Cadastro.
Sistema valida as informações preenchidas pelo Funcionário (EX01).
Sistema cadastra veículo (EX02) e volta para a tela inicial. Neste
momento, este caso de uso é encerrado.
Os campos devem estar todos preenchidos e de acordo com o domínio-ttlpo) do atributo" Se houver
problemas no preenchimento do formulário o sistema exibe a mensagem de erro: "Existem dados
inválidos no formulário ou algum campo não foi preenchido". . .
Caso o veículo já se encontre cadastrado, a mensagem "Este veículo já possui cadastro" é apresentada.
Tabela 4. Descrição do caso de uso Cadastrar Veículo.
de uso. A Tabela 4 apresenta o fluxo de ações envolvido
no caso de uso Cadastrar Veículo.
Novamente seguindo o processo definido no início do
artigo, retoma-se à Etapa 1 (Identificação de Classes). Nes-
te estudo de caso, as entidades encontradas foram Cliente,
Filial, Veículo, Funcionário, Dependente, Tipos de Veículo,
Cidade, Distância, Categoria de Frete, Fretes, Itens de Fre-
te, e Parâmetro (contendo o valor do km rodado) repre-
sentando elementos do domínio da aplicação.
A próxima etapa refere-se à identificação dos atributos
das classes. A Tabela 5 descreve os atributos identificados
a partir dos requisitos inicialmente definidos. Observa-se
novamente que não estão descritos os atributos de ligação-
entre as classes. Isso é papel dos relacionamentos.
A etapa seguinte refere-se à identificação das operações
das classes. A Tabela 6 resume esta etapa apresentando as
principais operações das classes do modelo. É importante
novamente ressaltar que muitas vezes a identificação das
operações pode ser feita posteriormente, ao se refinar o
diagrama de classes.
O último passo refere-se à identificação dos relacionamen-
tos e, para isso/efetua-se a análise dos casos de uso de forma
a encontrar estas relações entre as classes já identificadas:
• Generalização: verifica-se se há alguma relação "é
um tipo de" entre as classes identificadas. Neste es-
tudo de caso, como as classes Funcionario e Cliente
(ambos são pessoas físicas, pelo enunciado do estu-
do de caso) possuem atributos em comum (nome,
endereco, e telefone), optou-se por criar uma clas-
se PessoaFisica que agrupe estas características. Uma
dúvida poderia surgir em relação à classe Filial, que
possui os mesmos atributos. Neste caso, não será con-
siderada herança entre estas classes, mesmo conten-
do os mesmos atributos. Isso por que uma Filial não é
uma pessoa física e, portanto, não deve haver herança .
Classe Atributos
Nome
Cliente Endereco
Telefone
Nbme
Filial Endereco
ITelefone
Veiculo /(/ , NumPlaca
'I / ~
" "Matricula
Funclonario
Nome
"'" Endereco
, Telefone
Dependente
Nome
DataNascimento
I- Descricao '"'TipoVeiculo
" "••! 'Pesovlaximo" " ,
Cidade
Nome
Estado
Distancia Quilometros
Categoria Frete
Descricao
Percentual
Código
Frete Valor
NumNotaFiscal
ItemFrete
Descricao
Peso
Parametro ValorKmRodado
Tabela 5. Identificação dos atributos das classes.
Classe Operações
Frete
Cálcu)arFrete
EmitirNotaFiscal
Item Frete ObterPeso
Categoria Frete ObterPercentual
TipoVeiculo ObterPesoMaximo
Distancia ObterDistancia
Tabela 6. Identificação das operações.
UML na Prática - Construindo Diagramas de Classes Ano 3 34a Edição 51
--------------------------------------------------------~/
•
(a semântica" é um tipo de" não se aplica).
Associação: verifica-se se há a- necessidade de um
objeto de uma classe utilizar serviços disponibiliza-
dos por um objeto de outra classe ou, simplesmen-
te, "conhecer" o outro objeto. Neste estudo de caso,
observam-se várias associações no modelo, como
entre Frete e Cliente (um frete é' de um cliente e
um cliente pode fazer vários fretes), entre Frete e
Veiculo (um frete possui um veículo e um veículo
pode fazer vários fretes), entre Frete e Funcionaria
(um frete possui um funcionário responsável e um
funcionário pode ser responsável por vários fretes),
entre Frete e CategoriaFrete (um frete possui uma
categoria e uma categoriapode estar associada a vá-
rios fretes), entre Frete e Cidade (neste caso, existem
duas associações entre estas classes, uma vez que
um frete tem uma cidade representando sua origem
e outra seu destino e, além disso, cidades podem ser
origem e/ou destino de diferentes fretes), entre Filial
e Funcionaria (uma filial possui diversos funcioná-
rios e um funcionário está latada numa filial), entre
Filial e Veiculo (uma filial possui diversos veículos e
um veículo é de uma única filial) e, finalmente, en-
tre Veiculo e Tipoveiculo (um veículo tem um tipo e
um tipo pode estar associado a diferentes veículos).
Auto-Associação: verifica-se se existe alguma clas-
se que necessita ser relacionada a ela mesma. Neste
estudo de caso.existe uma auto-associação na classe
Cidade, representando que uma cidade pode estar
associada a diversas outras, representando as dis-
tâncias atendidas pela empresa de transportes.
Agregação: verifica-se se há alguma relação "parte
de" entre as classes identificadas. Neste estudo de
caso, não foi necessária a utilização de agregações.
Composição: verifica-se se há alguma relação "parte
de" forte entre as classes identificadas. Neste estudo
de caso identificam-se dois relacionamentos deste
tipo, um entre as classes Funcionaria e Dependente,
uma vez que os dependentes são como atributos in-
.ternos de funcionários; e outro entre as classes Fre-
te e ItemFrete, pelo mesmo motivo de estar repre-
sentando atributos internos que foram deslocados
para outra classe em função de suas características
próprias e também pela multiplicidade. Além disso,
a exclusão de um funcionário necessariamente im-
plica na exclusão de seus dependentes, bem como
a exclusão de um frete implica na exclusão de seus
itens. Nestes casos, modelam-se estas situações atra-
vés de composições.
Navegação: verifica-se se existem navegações des-
necessárias entre classes. Neste estudo de caso, na
associação entre as classes Veiculo e TipoVeiculo,
utilizou-se a navegabilidadeno sentido Veiculo ~
TipoVeiculo, uma vez esta última não precisa utilizar
nenhuma das operações definidas na classe Veiculo.
. O mesmo foi feito na associação entre as classes Fre-
te e CategoriaFrete, mantendo a navegabilidade no
sentido Frete ~ CategoriaFrete .
. Classe Associativa: verifica-se se existem informa-
ções que precisam estar vinculadas à associação de
dois objetos. Neste estudo de caso, a classe Distancia
está associada ao relacionamento entre dois objetos
da classe Cidade, representando a distância entre
elas. Modelam-se situações como esta utilizando
uma classe associativa.
Feito isto, chega-se à versão final do diagrama de classes
proposto pelo segundo estudo de caso, que pode ser visto
na Figura 16. Novamente, um refinamento deste diagra-
ma ainda precisa ser feito, definindo tipos de atributos e
assinaturas das operações, com seus eventuais parâmetros
de entrada e tipos de retorno, para o caso de funções ..
Percebe-se na versão final do diagrama da Figura 16 que
a classe PessoaFisica tornou-se abstrata (nome da classe
em itálico). A classe Cliente, apesar de não possuir atribu-
tos e nem serviços específicos, justifica-se pelo papel que
representa através da associação com a classe Frete.
Uma nova simbologia que surgiu neste diagrama é a
Dependência, encontrada entre as classes Frete e Parame-
tro, indicando que um Frete, para cumprir alguma de suas
funcionalidáj,ys(no caso, o cálculo do frete), depende de
serviços daclasse Parametro' (neste exemplo, aobtenção
do valor do quilômetro rodado). Este tipo de ligação in-
dica que a classe Frete utiliza os serviços da classe Para-
metro, mas não contém uma referência para esta, ou seja,
não possui um atributo do tipo da classe Parametro. Esta é
uma situação pouco indica da, pois está representando um
acoplamento entre as classes, situação não desejável em
qualquer. projeto de software. Entretanto, quando isto for
necessário, a UML disponibiliza esta representação gráfi-
ca. Assim, deve-se perceber que o valor do quilômetro ro-
dado não foi colocado na classe Frete, pois a cada instância
desta classe, este valor seria repetido. Neste caso, a classe
Parametro fornecerá o valor do quilômetro rodado, que
será utilizado no cálculo do frete.
Conclusão
Qualidade em sistemas de software passa pela qualida-
de das especificações e modelagem destes sistemas. Neste
sentido, a UML apresenta uma série de diagramas para a
construção de sistemas baseados no paradigma da orien-
tação a objetos. Dentre estes diagramas, o mais importante
é o diagrama de classes, que representa os elementos do
domínio do problema, composto pelas classes envolvidas,
seus atributos, operações e relacionamentos.
Este artigo teve o objetivo de apresentar os elementos
fundamentais para a construção destes diagramas de clas-
ses, discutindo situações de modelagem que levam à cons-
trução de sistemas bem projetados e, consequentemente,
de maior qualidade. •
52 SQLMagazine UML na Prática - Construindo Diagramas de Classes
•
•
•
•
Parametro Distancia
Vai orKmRodado Qui 10m etros~ - -
PessoaFiBica +0 bterVal orKm Rodad 00 +0 bterD istanciaO
-Nome
-Endereco '1\ 1
1
Dependente -Telefone 1 1
1
1
-Nome
~
1
-DataNascim ento 1 O ..•
1
Cliente 1
O." I • Ol,igem Cidade
1 1
1 , -Nome O."~ 1 1 I -Estado
1 ~.
I O."O.' I
Frete 1Fmcionario -Codigo
-Matricula 1 Destino-Valor O."O.' Itenf'rete-N umNotaF iscal
O." Veicuo 1 ..-1 -Descrtcao+CalcularFr~eO -Peso-NumPlaca O." +E m itirNotaFi scalO -- O."O." +0 bterP esoí)
O." . 1O." ~1
1 TipoVeiculo CategoriaFrete
Filial 1 -Deserieao -Deserícao
-Nome -P ésoM axim o -P ercentual
-Endereco
-Telefone +0 bterPesoM.imoO _+ObterPercentualO
/",1" "
t
I
f-I
I
I
I
!
I
I
I
!
!
Figura 16. Diagrama de Classes /
Programa de Usados da Tempo Real.
o melhor lugar para você vender seus livros
é o lugar onde você compra sempre.
Venda seus livros e compre muito mais!
Usados com garantia de avaliação e entrega.
A TEMPO REALinova oferecendo aos seus clientes a
possibilidade de vender seus livros usados em nosso
site. Você pode agora comprar seu livro, estudar e
aprender seu conteúdo e depois vendê-Io,
recuperando parte do seu investimento!
l
~'.
Acesse agora :
Awww.temporeal.com.br/usados
j ,1 é conheça esta exclusividade da Livraria do Profissional de Informática I.MlARIA DO PROFISSIONAl DE INFORMÁTlCA
UML na Prática" Construindo Diagramas de Classes Ano 3 34a Edição 53