142996443 ES JE04 DiagramaDeClasses PIM 12 05 13 (1)

Prévia do material em texto

Unified Modeling Language – UML
 Classe e Objeto
 Atributo
 Operação
 Associações (Delegações [SANTOS, 2003])
 Dependência
 Simples: multiplicidade, papel, navegabilidade
 Com valor semântico adicional: agregação e 
composição
 Generalização/especialização
 Diagrama de classes
 É uma descrição de um conjunto de objetos 
que compartilham os mesmos atributos, 
operações, relacionamentos e semântica
 É um tipo de (e dá origem a) objeto
 Qualquer elemento identificado no domínio 
do negócio que tenha:
 identidade - qualquer objeto é único e 
diferenciado dos demais
 estado - valores dos atributos em determinado 
momento
 comportamento – funcionalidade do objeto
 É a instância de uma classe.
 Definem os dados da classe
 Possuem tipo
 Podem ser referências (do tipo de) a outras 
classes (delegação)
 Possuem visibilidade, muito freqüentemente 
 privados
 O tipo de dado depende da linguagem de 
programação que será usada para 
implementação.
 Expressam o comportamento da classe
 Acessam e modificam os atributos da classe
 Na implementação, são os métodos 
(similares a procedimentos e funções)
 Possuem definição de visibilidade 
(geralmente públicas)
 Podem retornar valor ou não (void)
 Podem receber parâmetros ou não (entre 
parênteses obrigatórios)
 Serviços que a classe deve prestar 
(normalmente relacionados aos seus 
atributos)
 Parâmetros necessários a prestação dos 
serviços
 Retorno dos serviços prestados pela classe
 Saídas geradas pelos serviços da classe (não 
serão expressas no diagrama)
 Manutenção de classes persistentes 
(estereótipo <<entity>>)
 Definida por meio de modificadores de 
acesso:
 Público (public, +)
 Protegido (protected, #, depende de herança)
 Padrão (ausência de modificador, ~, pacote)
 Privado (private, –)
 Serve para encapsular, proteger, organizar o 
acesso à membros de uma classe
Nome
Atributos
Operações
public class Lampada {
 private String estadoDaLampada = “apagada”;
 public void acende() {
 estadoDaLampada = "acesa";
 }
 public void apaga() {
 estadoDaLampada = "apagada";
 }
 public void mostraEstado() {
 if (estadoDaLampada.equals("acesa")) {
 System.out.println("Esta acesa!");
 } else {
 System.out.println("Esta apagada!");
 }
 }
}
public class TestaLampada {
 public static void main(String[] args) {
 Lampada l1 = new Lampada();
 Lampada l2 = new Lampada();
 l1.mostraEstado();
 l1.acende();
 l1.mostraEstado();
 l1.apaga();
 l1.mostraEstado();
 
 l2.mostraEstado();
 l2.acende();
 l2.mostraEstado();
 }
}
 Associação mais fraca entre classes
 Indica utilização
 Geralmente acontece quando:
 Na passagem de parâmetro a um método
 Na criação de um objeto (e/ou referência) dentro 
de um método
 Relacionamento entre tipos mais genéricos e 
tipos mais específicos;
 Classe filha e a classe mãe;
 Relacionamento do tipo “é-um”;
 Aceita apenas a adição de características na 
classe filha; nunca a exclusão;
 Possibilita o reuso da estrutura e da 
funcionalidade;
 Necessária para o polimorfismo.
Aluno
matricula : String
Aluno()
Aluno()
toString()
Pessoa
nome : String
cursos : Vector
Pessoa()
adicionarCurso()
obtemCursos()
Professor
titulacao : String
Professor()
toString()
Professor()
public class Pessoa {
private String nome;
private Vector cursos;
}
public class Aluno extends Pessoa {
private String matricula;
}
 Ligação estrutural entre duas classes
 Permite navegar de um objeto para outro
 Tempos de vida independentes.
Curso
Professor
public class Curso{
 ...
 Private Professor responsavel;
 
 public void setResponsavel(Professor aResponsavel){
 responsavel = aResponsavel;
 }
 public Professor getResponsavel (){
 return responsavel;
 }
}
 Adiciona valor semântico (pouco) a 
associação, indicando que uma classe é mais 
importante na associação
 Associação do tipo “parte-de”
 Tempo de vida independente: a existência 
da parte não está vinculada ao tempo de vida 
do todo, podendo a parte compor outros 
todos
Materia
Curso
0..*
0..*
0..*
-materias
0..*
A agregação apenas 
adiciona valor semântico ao 
modelo, mas não modifica a 
forma de implementação, 
que permanece como a da 
associação simples.
 Conotação semântica mais forte que a 
agregação
 Denota forte interdependência entre as 
partes
 Tempo de vida dependente
 A multiplicidade do lado do “todo” não pode 
ser maior que 1, pois a parte é exclusiva de 
um todo
Carro
Peca
 Nome 
 Papel 
 Navegabilidade
 Multiplicidade
 Demonstra o objetivo da associação
 Deve ser uma frase com verbo
 É preferível usar papeis ao invés do nome do 
relacionamento
 Normalmente utilizada no modelo em fase 
de análise, quando ainda não existem 
informações suficientes para nomear os 
papéis
Curso Professor
Indica o responsavel
 Descreve a função da classe na associação
 Deve ser um substantivo
 Não deve ser usado junto com o nome de 
associação
 Há situação em que o papel designará o 
nome de um atributo, na implementação de 
uma das classes. Nesse caso, deve ser 
colocado no modelo.
Curso Professor-responsavel
 Indica que, a partir de um objeto, é possível 
chegar a outro que esteja associado a ele
 Pode ser implementado por:
 Referência a objetos
 Arrays ou coleções de objetos
 Quando não especificada, assume-se a dupla 
navegabilidade (mais complexa)
 Nunca há setas nas duas extremidades da 
associação
Curso Professor
 Indica quantos objetos de uma classe podem 
ser associados
 Pode ser qualquer número de zero até muitos 
(indicado por *)
 Valores mais comuns:
 0..* - zero ou qualquer número maior
 1 - obrigatoriamente um e apenas um
 1..* - um (no mínimo) ou qualquer número
Curso Professor10..*
 É criado para representar o conjunto das classes e 
suas associações
 É a base estrutural que dá suporte a todas as 
funcionalidades de um sistema
 Serve como modelo conceitual e lógico de dados
 Constitui mais uma forma, junto com diagramas de 
casos de uso, de comunicação bastante útil entre 
projetistas e clientes
 Identifica os objetos manipulados pelo sistema
 Deve ser desenvolvido nas versões necessárias a 
compreensão de cada uma das fases do ciclo de vida 
do software (análise, projeto, implementação)
 É formal e pode servir para geração de código em 
uma linguagem de programação
 Trata-se de uma representação estática: é 
importante para definir que classes prestarão cada 
uma dos serviços demandados pelo sistema
 Na locadora, os funcionários são identificados por CPF, 
nome, endereço, telefone e salário. Já os veículos estão 
divididos em: popular, luxo e utilitário. Sobre os veículos 
deve-se saber: placa, tipo, modelo, ano, cor, chassis, 
quilometragem e valor do aluguel diário e semanal. Os 
funcionários serão responsáveis por efetuar o aluguel de um 
carro para um cliente e dar baixa no aluguel. Existem clientes 
especiais e clientes comuns, sendo que os especiais possuem 
uma taxa de desconto e uma quilometragem extra, definida 
individualmente. O cliente é identificado por RG, nome, CPF, 
telefone, endereço. Os endereços de funcionários e clientes 
devem conter: rua, número, cidade e CEP. Este deve ser 
validado junto à ECT. 
 Alugar Carro: um cliente solicita ao funcionário o aluguel do 
carro. O sistema verifica se o carro solicitado pelo cliente 
está disponível.Caso esteja, o processo de locação é 
concluído e o carro passa a estar indisponível. A data de 
aluguel deve ser usada para cálculo do valor do aluguel na 
momento da devolução.
 Dar Baixa: um cliente faz uma devolução para um 
funcionário e solicita nota fiscal com a quilometragem 
percorrida e o valor do aluguel. O funcionário dá baixa na 
locação e o carro passa a estar novamente disponível. O 
funcionário solicita ao sistema para calcular o valor a ser 
pago e, se for de interesse do cliente, emitir o recibo.
 Cadastrar Cliente: cliente solicita ao funcionário o cadastro 
na locadora. O funcionário recebe os dados e efetua o 
cadastramento.
 Cadastrar Carro: funcionário cadastra o carro adquirido.
 Um cliente primeiramente se dirige à Clínica onde marca uma consulta com a 
secretária, fornecendo suas informações pessoais e do animal que deseja tratar. 
Se o cliente ou o animal ainda não estiverem cadastrados no sistema ou possuam 
algum dado que precise ser atualizado, a secretária deverá atualizar seus 
cadastros.
 Em cada sessão de tratamento (uma sessão equivale a uma consulta), o cliente 
deve informar os sintomas aparentes do animal e estes devem ser registrados. 
Um tratamento pode ser encerrado em apenas uma consulta, quando se tratar de 
algo simples ou pode se arrastar por muitas sessões dependendo do diagnóstico 
do médico-veterinário.
 Durante uma sessão o veterinário pode marcar exames para o animal, a serem 
trazidos na sessão seguinte, O pedido dos exames, bem como seus resultados 
devem ser registrados no histórico de tratamentos do animal.
 Após cada sessão, o histórico da consulta deve ser atualizado e gera-se uma 
conta a receber a ser paga pelo cliente. A manutenção das consultas é 
responsabilidade exclusiva do médico-veterinário que a realizou.
 É responsabilidade da secretária manter atualizados os cadastros de clientes, 
animais, médicos e espécies.
 O sistema aceita submissões sobre diversos temas como Engenharia de 
Software, Banco de Dados, Hipermídia, sendo necessário, portanto manter um 
cadastro de todos os temas aceitos.
 Um autor pode realizar muitas submissões. Uma submissão pode constituir-se 
em um artigo, um mini curso ou palestra. As submissões só podem ser realizadas 
através da Internet. Ao acessar a página de submissão o autor pode logar-se, 
realizar uma submissão ou verificar a situação de trabalhos porventura já 
submetidos, no entanto, para poder utilizar os dois últimos serviços ele deverá 
antes executar o primeiro.
 Um autor deve registrar-se no sistema antes de poder se logar. Se já estiver 
registrado deverá então logar-se, informando seu login e senha.
 Toda submissão precisa ser avaliada por uma comissão de três avaliadores, 
responsável por analisá-la e fornecer notas. Um avaliador pode avaliar muitas 
submissões. As submissões são aprovadas de acordo com as maiores notas 
gerais. A nota geral de uma submissão será o resultado da média de todas as 
notas das avaliações de cada submissão. As n melhores notas de cada tema e tipo 
serão consideradas aprovadas. É necessário manter-se um cadastro de todos os 
avaliadores do congresso.
 É responsabilidade do coordenador do evento definir quais avaliadores avaliarão 
quais submissões. E também responsabilidade do coordenador notificar os 
autores sobre a aceitação ou não de suas submissões no evento.
 O coordenador pode emitir o relatório das avaliações sempre que quiser, no 
entanto, a partir do momento em que selecionar a opção notificar autores, estes 
serão avisados se suas submissões foram ou não aprovadas.
 Sendo ou não aprovada, uma submissão pode ou não receber comentários dos 
avaliadores, referentes a possíveis alterações necessárias antes da submissão ser 
publicada e disponibilizada no congresso ou informações ao autor do por que da 
não aprovação de seu trabalho pelo avaliador.
 Um autor pode consultar o estado de suas submissões, ou seja, se elas estão 
ainda sob avaliação, foram aprovadas ou reprovadas. Um autor pode também, se 
assim o desejar, verificar os possíveis comentários dos avaliadores a respeito de 
uma submissão específica.
Observações  Complementares:
 O Autor pode realizar login, registrar-se, realizar submissão, verificar submissões 
e verificar comentários. Observe que o Autor somente poderá se auto-registrar a 
partir a partir de uma tentativa realizar o login e assim mesmo se ainda não 
estiver registrado, o que indica o uso de uma associação e extensão. 
 Da mesma forma, a consulta a comentários só pode ser feita a partir de uma 
consulta a submissões. A realização das submissões e o seu acompanhamento só 
podem ser feitos se o autor tiver logado.
 O avaliador para emitir seus comentários sobre as submissões deve ter 
informado sua avaliação previamente. 
 O aluno primeiramente solicita informações ao atendente 
sobre quais cursos a empresa oferece. Se o aluno se 
interessar por algum curso, pedirá informações a respeito de 
quais turmas, do curso em questão, estão abertas, qual o 
horário em que as aulas serão ministradas, qual a data 
prevista para início das aulas e qual o mínimo de alunos 
necessários para que uma turma inicie o curso.
 Caso o horário de alguma turma seja compatível com os 
horários do aluno, este realizará a matrícula em uma turma 
relativa ao curso em que se interessou. Caso o aluno nunca 
tenha feito nenhum curso na empresa e, portanto, não 
esteja cadastrado, o aluno deverá ser registrado antes de 
realizar a matrícula.
 Um cliente (pessoa física ou jurídica que paga o advogado para defendê-
la ou para processar outra pessoa) procura o advogado. Se o cliente 
ainda não estiver cadastrado, o advogado deverá registrar seus dados 
pessoais.
 Em seguida, o cliente deve fornecer informações a respeito do processo 
que deseja que o advogado mova contra alguém ou que o defenda de 
outra pessoa. Obviamente o processo precisa ser registrado e receberá 
diversas adições enquanto estiver em andamento. O cliente deve 
fornecer também informações sobre a parte contrária (pessoa física ou 
jurídica que está processando ou sendo processada pelo cliente), que 
deverá também ser registrada, caso ainda não esteja. Observe que uma 
mesma pessoa física ou jurídica pode ser tanto um cliente como uma 
parte contrária em períodos diferentes, obviamente.
 Um processo pode gerar custas (despesas com xérox, viagens etc.). Cada 
custa deve ser armazenada de forma a ser cobrada da parte contrária 
caso o processo seja ganho.
 Este sistema deve estar integrado a um sistema de contas a pagar e 
receber, cada custa gera uma conta a pagar. Caso o processo seja ganho, 
ele gerará uma ou mais contas a receber, dependendo da negociação 
com a parte contrária.
	Slide 1
	Slide 2
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Slide 10
	Slide 11
	Slide 12
	Slide 13
	Slide 14
	Slide 15
	Slide 16
	Slide 17
	Slide 18
	Slide 19
	Slide 20
	Slide 21
	Slide 22
	Slide 23
	Slide 24
	Slide 25
	Slide 26
	Slide 27
	Slide 28
	Slide 29
	Slide 30
	Slide 31
	Slide 32
	Slide 33
	Slide 34
	Slide 35
	Slide 36
	Slide 37
	Slide 38
	Slide 39
	Slide 40
	Slide 41
	Slide 42
	Slide 43
	Slide 44
	Slide 45
	Slide 46
	Slide 47
	Slide 48
	Slide 49
	Slide 50
	Slide 51