Você está na página 1de 87

Modelagem de Classes e

Objetos

JAVA em UML

Profa Claudete Moscardini


Pontifícia Universidade Católica de Minas Gerais
Ciência da Computação
Programação
• Ciclo de Vida de um Sistema
• UML (Unified Modeling Languade)
• Modelagem de Classe
• Classe  JAVA
• JUDE UML – Gerar e Importar código
JAVA
Bibliografia
• LARMAN, Craig. Utilizando UML e Padrões. 2ª Ed.
Editora Bookman.

• KNOERNSCHILD, Kirk. Java™ Design: Objects,


UML, and Process

• SANTOS, Rafael. Introdução à Programação


Orientada a Objetos Usando JAVA.Ed. Campus

• www.uml.org
• www.sun.org
Tecnologias utilizadas para o
desenvolvimento Orientado a Objeto
• Modelagem:
− UML (Unified Modeling Language)

• Desenvolvimento:
− Java

• Armazenamento:
− Objetos persistentes
Arquitetura de uma aplicação Java
Java Virtual
Aplicação Machine

API JDO PersitenceManager

Implementação JDO

API JDBC
BD
Driver JDBC
Vantagens da Arquitetura anterior
• Portabilidade,
• Independência de Banco de Dados,
• Facilidade de uso,
• Maior Performance
Ciclo de Vida do

Desenvolvimento do software
Modelo de ciclo de vida

• O envolvimento de uma fase com a outra


é conhecido por ciclo de vida do sistema.
• Existem vários modelos de processo de
software (ou paradigmas de engenharia de
software).
• O modelo tenta colocar ordem em
atividades inerentemente caótica.
Modelos de Processo de Software
• Modelo Cascata
• Modelo de Prototipação
• Modelo RAD (Rapid Application Development)
• Modelos Evolutivos de Processo de Software
− Modelo Incremental
− Modelo Espiral
− Modelo de Montagem de Componentes
− Modelo de Desenvolvimento Concorrente
− RU (Unified Process)
• Modelo de Método Formais
• Técnicas de Quarta Geração
Modelo em Cascata
• Chamado de clássico ou linear por possuir
tendência na progressão seqüencial entre
uma fase e a seguinte.
• O resultado de uma fase se constitui na
entrada da outra.
Modelo Cascata

Engenharia de
Sistemas
Análise de
Requisitos
Projeto

Codificação

Testes

Manutenção
Problemas do Modelo de Cascata
• Difícil estabelecer todos os requisitos
logo no início.

• Demora na geração de uma versão


executável do software.

• Na prática é difícil um sistema seguir o


fluxo seqüencial que o modelo propõe.
Benefícios do Modelo Cascata
• Impôs disciplina, planejamento e
gerenciamento.

• A implementação só ocorre quando os


objetivos tenham sido completamente
entendidos.
Modelo de Prototipação
• Tem como objetivo o entendimento dos
requisitos do usuário.

• Apropriado para quando o cliente não ainda


definiu os requisitos.

• O cliente deve ser esclarecido desde o início


que o protótipo é construído apenas para
servir como mecanismo para definir os
requisitos.
O Paradigma de Prototipação para
obtenção dos requisitos

Obter Requisitos

Elaborar Projeto Rápido


Refinamento do Protótipo

Construir Protótipo
Avaliar Protótipo
Problemas com a Prototipação
• Cliente não sabe que o software que ele vê
não considerou, durante o
desenvolvimento, a qualidade global e a
manutenibilidade a longo prazo.

• Desenvolvedor freqüentemente faz uma


implementação comprometida (utilizando o
que está disponível) com o objetivo de
produzir rapidamente um protótipo.
Modelo RAD (Rapid Application Development)

• É um modelo seqüencial linear que


enfatiza um ciclo de desenvolvimento
extremante curto, utilizando na
construção componentes.

• As atividades são desenvolvidas em


“fogo-rápido” a fim de terminar o
projeto em curto prazo.
O que é o desenvolvimento
iterativo e incremental?
 É o processo de construção de sistemas de
software feito em pequenos passos.
 Requer uma compreensão crescente do domínio
por meio de aperfeiçoamento sucessivos e do
desenvolvimento incremental de uma solução
efetiva em vários ciclos.
Benefícios:
• Redução do risco devido a uma percepção prematura
do domínio.
• Aumento da flexibilidade de alteração/manutenção
• melhoria na qualidade do produto.
Modelo Incremental

• É uma combinação entre o modelo em


cascata com a filosofia iterativa da
prototipação.

• O objetivo é trabalhar junto do usuário


para descobrir seus requisitos, de
maneira incremental, até que o produto
final seja concluído.
PU (Processo Unificado)
 PU: surgiu como um processo para desenvolvimento
de software orientado a objetos.

 Rational Unified Process (RUP): refinamento


detalhado do PU. Consiste de uma abordagem do
ciclo do processo de desenvolvimento de sistema
adequada à UML.

 É um processo Iterativo e incremental.


(RUP) Processo Racional Unificado
O RUP é estruturado junto a duas dimensões:
• TEMPO - divisão do ciclo de vida em fases e iterações
Fases do Processo : Concepção, Elaboração, Construção e
Transição
• COMPONENTES DE PROCESSO - produção de um conjunto
específico de artefatos com atividades bem definidas.
• Atividades de processo: levantar necessidades,
análise e projeto, implementação, testes
• Atividades gerenciais: Gerenciamento, ambiente,
produção
Fases e iterações
ITERAÇÃO - “Representa um ciclo completo de
desenvolvimento, desde a captação de requisitos na
análise até a implementação e a realização de
testes”
• Resulta na liberação de um subconjunto do
produto final.
• cada liberação é uma ´parte ´ completa do
sistema final.
•A Redução de riscos orienta as iterações.
Fases e iterações
Fases do Processo Unificado (PU):
2. Concepção - Estabelece o caso de negócio para o
projeto, escopo e estimativas vagas.
3. Elaboração - Estabelece um plano de projeto e
uma arquitetura sólida.Identificação da maioria dos
requisitos e do escopo e estimativas mais realistas.
4. Construção - desenvolve o sistema e preparação
para implantação
5. Transição – testes e implantação.

Concepção Elaboração Construção Transição


Tempo
Processo Rational UML - Fases
e iterações
Fases e iterações
Fase de Concepção
Objetivo :
Estabelecer qual o negócio para o novo sistema ou para
uma atualização de um sistema já existente e delimitar o
escopo do projeto. Conseqüentemente será critério de
sucesso do projeto.

Produtos:
• avaliação inicial de riscos
• estimativa de recursos necessários
Fases e iterações
Elaboração
• Deseja-se neste ponto do desenvolvimento obter um
melhor entendimento do problema: definir o que
construir, como construir e a tecnologia a utilizar.
• Como ponto de partida, deve-se direcionar pelos riscos
existentes no projeto. Os riscos podem, em primeira
análise, ser classificados nas seguintes categorias:
− Riscos de requisitos.
− Riscos tecnológicos
− Riscos de habilidade
− Riscos políticos
Fases e iterações
Elaboração
• Desenvolve-se um plano de como será
realizado o projeto.
• Estabelece-se a arquitetura do sistema.
• Produtos: cenários de contexto do
sistema, documento de avaliação de
riscos.
Fases e iterações
Construção
• Nesta fase o sistema é construído em uma série de iterações.
Cada iteração envolve análise, projeto, codificação, testes.
•As iterações na construção são incrementais e iterativas.

• Alguns produtos :
•Uma série de executáveis
•protótipos
•resultados do controle de qualidade
•Critérios de avaliação para a próxima iteração
•documentação do sistema
Fases e iterações
Transição
• Objetivo: tornar o software disponível à sua
comunidade de usuários.

• Alguns produtos :
•Avaliação do sistema
•Definição sobre necessidade de novas iterações
•resultados do controle de qualidade
•documentação atualizada do sistema
Introdução

Unified Modeling Language (UML)


Introdução à UML
• É uma linguagem padrão adota pelos OMG(Object Management
Group) para a elaboração da estrutura de projetos de software.

• Visualizar, especificar, construir e documentar um sistema.

• Pode ser usada com todos os processos ao longo do ciclo de


desenvolvimento, e com diferentes tecnologias de implementação.

• É independente tanto de linguagens de programação quanto de


processos de desenvolvimento.
Notação UML
• É uma mistura da sintaxe gráfica de vários
autores. Statecharts
 Grafo de Interação FUSION
(Coleman) (Harel)
de Objetos
 Diagrama de Statecharts
(Diagrama de Atividades)

BOOCH OMT
UML (Rumbaugh)
 Diagrama de Estados
 Diagrama de Classes
 Diagrama de Classes
 Diagrama de Estados
 Diagrama de Objetos
(Diagrama de Colaboração)
 Diagrama de Processos
(Diagrama de Deployment) OOSE  Diagrama Use Cases
 Diagrama de Módulos (Jacobson)  Subsistema (Package)
(Diagrama de Componentes)
Importância de vários modelos
• A modelagem permite a compreensão
de um sistema.
• Nenhum modelo é inteiramente
suficiente.
• Múltiplas visões do sistema, permitindo
que um modelo complemente os outros.
Diagramas UML
Diagrama Estático
1. Classes
2. Objetos
3. Pacotes
4. Estrutura Composta (versão 2.0)
5. Componentes
6. Implantação
Diagrama Dinâmico
1. Estados (versão 1.5)  Máquina de Estado (versão 2.0)
2. Casos de Uso
3. Atividades
4. Interação
10.1 Seqüências
10.2 Colaborações (versão 1.5)  Comunicação (versão 2.0)
10.3 Integração Geral (versão 2.0) – Interaction OverView
10.4 Tempo (versão 2.0) - Timing
Diagramas UML
Diagrama

Diagrama Estático Diagrama Dinâmico

Classes Objetos Pacotes Implantação Máquina de Estados Caso de Uso Atividade

Estrutura Composta Componente Interação

Seqüência Comunicação Interação Tempo


Geral
Mecanismos de extensibilidade
• Estereótipo: [de estero + tipo]: elemento sólido + tipo =>
tipo de forma compacta.
• Estereótipos (Stereotype): uma classe dentro do
metamodelo da UML. Ex: <<nome-stereotype>>,
<<Actor>>, <<use>>, etc. Quando você quer utilizar itens
novos, utilizando seu vocabulário próprio e com a
aparência dos blocos primitivos.
• Valores Atribuídos: novas informações na especificação
de um elemento. Ex: autor e versão.
• Restrições: acrescentar novas regras.
Mecanismos de extensibilidade
Estereótipo Valores Atribuídos

< < e xc e ç ã o > >


C lie n te {ve rs io n = 3 .2 a u to r = jo ã o }

a d i ci o n ar ()
{o rd e n a d o }
e x clu ir ()

Restrições
Blocos de construção da UML
1. Itens:
1. Estruturais: parte estática do modelo. Classe, Interface,
Colaborações, Caso de uso, componentes.
2. Comportamentais: parte dinâmica do modelo, troca de
mensagens entre os objetos. Interação e máquina de
estado.
3. Agrupamentos: parte organizacional do modelo. Pacote.
4. Anotacionais: parte explicativa do modelo.
2. Relacionamentos: dependência, associação, generalização e
realização.
3. Diagramas
Relacionamento

1. Dependência: a alteração de um item afeta


o item dependente.

2. Associação:

3. Generalização: os filhos compartilham a


estrutura e o comportamento do pai.
Modelagem de

Classe
Diagrama de Classe
• É uma representação gráfica para descrições genéricas
do sistema.
• Contém os seguintes itens :
− Classes

− Interfaces

− Colaborações

− Relacionamentos de dependência, generalização,


associação e agregação.
• São superconjunto dos diagramas de entidade-
relacionamento, uma ferramenta básica de modelagem
para o projeto lógico de banco de dados.
Classe
• Uma boa classe capta uma, e apenas
uma, abstração.Ela deve ter um tema
principal.
• Ex: Uma classe que mantem as
informações do aluno e mais as
disciplinas que ele cursou não é uma
boa classe. => crie duas classes :
Aluno + DisciplinaCursada
Classe
• Estrutura e comportamento de um
conj. de objetos. Atributos e Métodos
são opcionais.
Nome da Classe
Atributo
Atributo : tipo do dado
Atributo : tipo do dado = valor inicial

Operação
Operação ( lista de argumentos) : tipo de resultado

Colaboração
• Nenhuma classe é utilizada sozinha.
• Cada classe funciona em colaboração
com outras.
• É importante observar nas classes:
− Visualização das classes.
− Especificar.
− Documentar as várias formas possíveis.
Tipos de Visibilidade
• Visibilidade : como a classe é vista fora do pacote que
é definida. A visibilidade por elementos ( atributo ou
método).
− Pública: todos tem acesso, no caso de atributo
permite que operações de outras classes podem
utilizá-lo.
− Protegida: os elementos podem ser acessados pela
mesma classe, por subclasses ou por classes
friends.
− Privada: os elementos são acessíveis somente pela
própria classe ou por classes friends.
− Implementação: os elementos são acessíveis
somente pela própria classe.
Generalização
• É uma superclasse tem atributos, operações e
associações comuns a classes especializadas.
• O triângulo vazio fica no término do caminho que
satifaz o elemento mais geral.
Pessoa
Codigo : Integer
Nome : String

PessoaFisica PessoaJuridica
CPF : String CGC : String
Multiplicidade
Notação Significado
0..1 Zero ou uma instância
1 Somente uma instância
0..* Zero ou mais instâncias
* Default, núm ilimitado.
1..* Um aou mais instâncias.
<literal>..* Núm. exato ou mais instâncias.
<literal> O núm exato de instâncias.
<literal>..<literal> Faixa de instâncias especificadas.
<literal>..<literal>,<literal> Núm. de instâncias será na faixa especifica
ou núm. exato de instâncias.
Dependência
• Uma classe depende de outra classe
para sua sobrevivência.
• Ex: uma classe dependente depende
da classe funcionário para sobreviver.
F u n ci o n a ri o D e p e n d e n te

1 0 ..n
Associação
• Relacionamento mais utilizado.
• Bidirecional.

Fo rn e ce d o r Pe d i d o

1 0 ..n
Agregação
• Forma especial de associação.
• É conhecido também por “todo-parte”.
• O objeto do todo contém os objetos das partes.
• Existe um compartilhamento do objeto “parte” com
outros objetos “todo”.
• Agregação por referência ou regular.
TODO PARTE

Côm odo P arede


Agregação de composição
• Ou Agregação por valor: o objeto todo declara uma
instância real do objeto parte dentro do seu próprio
corpo tornando o objeto parte fisicamente nele
contido.
• Um objeto poderá ser uma parte de somente uma
composição em determinado momento.

Ja n e la M ol d u ra
Navegabilidade
• Uma instância de uma classe pode navegar a
instâncias de outra classe e vice-versa.
• Um objeto usuário poderá encontrar os objetos
senha correspondente, mas considerando uma
senha, não é desejado indentificar o usuário
correspondente. n
U s u á ri o 1 Se nha

P e d id o 1 C l ie n te
n
A qual cliente
pertence o pedido

Sentido da navegabilidade
Operações polimórficas
• Mesma assinatura definidas em
diversos níveis de uma hierarquia de
generalização.
Operações abstratas
• Ela não possui implementação.
• Uma classe que possui pelo menos uma
operação abtrata é também abstrata.
Pacotes
• Facilita o gerenciamento do sistema.
• Facilita a reutilização das classes.
• Grupo de classes relacionadas logicamente.

• Quando surge a necessidade de se criar


pacotes?
− Sistemas simples X Sistemas Complexos
Modelos de Domínio
• Composto por
− Objetos do domínio ou classes conceituais;

− Associações entre classes conceituais;

− Atributos de classes conceituais.

• Considerado um dicionário visual das abstrações.


• Não se deve representar classe:
− “amarrada” a tecnologia como; Java, C++.

− artefatos de software, como janela ou um banco


de dados.
− métodos
Classes conceituais
• Identifique as classes no cenário.

• Existem classes sem atributos, elas


são conhecidas por ser puramente
comportamental.
Identificar classe conceitual

venda venda loja


Ou ...?
loja númTelefone

• No mundo real, uma loja não é considerada


um NÚMERO ou TEXTO – o termo sugere
uma entidade legal, uma organização que
ocupa espaço.
E neste caso, Destino é um
conceito?

Vôo
Destino
Classes conceituais de
Especificação ou de Descrição
• Armazena informação.
• Exemplificando, na venda de um Produto
seria chamada de
EspecificaçãoDeProduto, mesmo que
todas as instâncias deste produto seja
vendido, sua especificação permanecerá.
Item EspecifiçãoProduto
* Item
descrição descrição 1..1
preço Série
preço itemID
Série
itemID
Quando as classes de
especificação são necessárias?
1. Houver necessidade de uma descrição sobre
um item ou serviço.

3. Resultar em uma perda de informação que


precise ser mantida.

5. Reduzir informações redundantes ou


duplicadas.
Modelo do Domínio do PU x Modelo de
Projeto do PU

Modelo de Projeto
Alguns termos utilizados
1. Classe conceitual: um conceito ou coisa
do mundo real. Representada no Modelo de
Domínio..
2. Classe de projeto: sinônimo de classe de
software mas tem perspectiva de
especificação ou implementação, conforme
o modelador deseja.
3. Classe de implementação: classe
implementada em uma linguagem orientada
a objetos, como JAVA.
Modelo de Domínio: Inclusão de
Atributos.
• São sugeridos pelos requisitos (por exemplo, casos
de uso) sugerem.

• Os atributos não devem ser usados para relacionar


classes conceituais no modelo de domínio.

• Atributo derivado: um atributo que pode ser derivado


de outras informações. Na UML, o atributo derivado
é indicado com um símbolo “/”.
Modelo de Domínio
• Capta as abstrações essenciais e as
informações necessárias para
compreender o domínio do contexto
dos requisitos.

• Auxilia na compreensão do domínio;


seus conceitos, terminologia e
relacionamentos.
Estereótipos
• Maneira de destacar ou diferenciar um
componente.
• Características especiais ou
• Modificando-as de alguma forma.
Estereótipo <<entity>>
• Torna explícito que uma classe é uma
entidade.
• São objetos que terão um período de
vida longo.
• Não significa que a classe ou objeto
será persistente.

Submissão
Estereótipo <<boundary>> e
<<control>>
• <<boundary>> ou estereótipo de fronteira:
− identifica uma classe que serve de
comunicação entre os atores externos e o
sistema.
− é importante quando há a necessidade de
definir a existência de uma interface para o
sistema.

• <<control>>: classes intermediárias entre as


classes <<boundary>> e as classes do
sistema.
Estereótipo <<boundary>> e
<<control>>
• <<control>>: responsável por interpretar
os eventos ocorridos sobre os objetos
<<boundary>>, como movimentos do
mouse ou o pressionamento de um
botão.

Página Congresso Controlador Congresso


Definições de Classe

em JAVA

Mapeamento CLASSE UML em JAVA


Definições de Classe
• Campos,
• Construtores e
• Métodos
Campos ou Variáveis
• Os campos são pequenas quantidades de
espaço dentro de um objeto que podem ser
utilizados para armazenar valores.

public class TicketMachine


{
Private int price;
Private int balance;
Private int total;
....}
Modificadores de Acesso
• Public x Private
− Public: declara um elemento de uma
classe (um campo ou método) como
parte da interface (publicamente visível).
− Private: declara um campo ou método
como parte da implementação (oculto do
acesso externo)
Construtores
• Inicializar campos de instâncias, garantindo aos
métodos valores específicos e não os default.
• Construtores devem te exatamente o mesmo nome da
classe a que pertence.
• Não podem retornar nenhum valor
• Não devem receber modificadores public ou private
• O compilador executa automaticamente um construtor,
quando uma instância da classe a qual ele pertence for
inicializada com a palavra new.
Exemplo de Construtor
class Evento // declaração da classe
{
private String nomeDoEvento, localDoEvento;
private Data inicioDoEvento, fimDoEvento;

Evento (String n, String l Data i, Data f) //Construtor


{
nomeDoEvento = n; localdoEvento = 1;
inicioDoEvento = new Data();
inicioDoEvento.inicializaData(i.retornaDia(), i.retornaMes( )
, i.retornaAno( ))
fimDoEvento = new Data();
fimDoEvento.inicializaData(f.retornaDia(), f.retornaMes( )
, f.retornaAno( ))
} // fim do construtor
......
}
Valores Default
• Caso não exista inicialização de
instâncias os seguintes valores serão
adopatos:
− Boolean = FALSE
− Char = espaço
− Byte, short, lont, int, float ou double =
Zero
− String = NULL
Métodos
UML versus JAVA
Classe

Java UML
Public class Empregado {
private int empID; Empregado
empID : int

+calcSalario () : double
public double calcSalario( ) {
.........
}
}
Pacote
•O Pacote pode conter outros pacotes, classes ou ambos.

Java UML
package ObjetosNegocio;

public class Empregado( ) {


}
Interface
• Interface é uma coleção de operações que
especificam um serviço de uma classe.
Java UML
public interface ItemL {

public abstract void windowOpened();


public abstract void windowClosing();
}
Dependência

Java UML
public class Empregado {
public void AdicionarDependente( dependente
d) { .....
}

}
Associação

Java UML
public class Empregado {

private Projeto[] projeto;

}
Agregação

Java UML
public class Empregado {
private TipoEmpregado[] tipoEmpregado;

public TipoEmpregado getTipoEmpregado()


{ return null;
}
...}
Generalização

Java UML
Public abstract class Empregado {

}
public class Gerente extends Empregado {
}
public class Vendedor extends Empregado{
}
Realização
• A classe Empregado vai implementar todas as interfaces da
classe ColecaoEmpregado

Java UML
public interface ColecaoEmpregado {
}
public class Empregado implements
ColecaoEmpregado {

}
Anotação

Java UML
/**Este é um exemplo UML.
Comente seu programa JAVA*/