Analise e projetos orientados a objetos

– APOO –
(OOA&D)

Análise e Projeto de Sistemas
Orientados a Objetos
(Object-Oriented Analysis & Design )

Prof. Ricardo Luiz
Carga Horária: 32 horas/aula

1

APOO - Análise e Projeto de Sistemas Orientados a Objetos
EMENTA
• CICLO DE VIDA DE UM SISTEMA
• MODELO DE NEGÓCIO
• DEFINIÇÃO DOS REQUISITOS
• ANÁLISE E PROJETO
• O MODELO OBJETO
• CONCEITOS DO PARADIGMA OBJETO
• UML: TÉCNICAS, MÉTODOS E METODOLOGIAS
• FERRAMENTAS DE ANÁLISE: EVOLUÇÃO E ESTADO ATUAL
• EXERCÍCIOS DE PRÁTICA UTILIZANDO FERRAMENTAS
CASE VOLTADAS PARA A ANÁLISE E PROJETO DE
SISTEMAS ORIENTADOS A OBJETOS

Prof. Ricardo Luiz 2

BIBLIOGRAFIA
• Bibliografia Básica:

WAZLAWICK, Raul Sidnei. Análise e projetos de sistemas de
informação orientados a objetos. Rio de Janeiro: Elsevier,
2004.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML:
guia do usuário. 2.ed. Rio de Janeiro: Elsevier, 2005.


1

BIBLIOGRAFIA
• Bibliografia Complementar:

LARMAN, Craig. Utilizando UML e padrões: uma introdução à
análise e ao projeto orientados a objetos. 2.ed. Porto Alegre:
Bookman, 2004.
FOWLER, Martin et al. UML essencial. 3.ed. Porto Alegre:
Bookman, 2005.
KRUCHTEN, Phillippe. Introdução ao RUP: rational unified
process. Rio de Janeiro: Ciência Moderna, 2003.
CARDOSO, Caíque. UML na prática: do problema ao sistema.
Rio de Janeiro: Ciência Moderna, 2003.
GUEDES, Gilleanes. UML 2: guia de consulta prática. 2.ed. São
Paulo: Novatec, 2005.


LINKS ÚTEIS

www.wthreex.com/rup/index.htm
www.mundooo.com.br
www.aspercom.com.br
www.cpgei.cefetpr.br/~stad/Apostila%20de%20UML%20CEF
ET.pdf
https://jude.change-vision.com/jude-
web/product/community.html
www.uml.org


PLANO DE AULA
• Introdução aos Conceitos da Orientação a Objetos
• Os Softwares nos Dias Atuais
• Crise do Software
• Metodologia RUP
• Linguagem de Modelagem UML
• Diagramas da UML
• Apresentação da Ferramenta CASE : JUDE
• Exercícios de Prática Utilizando JUDE


2

AVALIAÇÃO
• DIVIDIDA EM DUAS PARTES:
• PROVA ESCRITA
• VALOR: 4,0 PONTOS
• DATA DE APLICAÇÃO: 29/08/2006
• TRABALHO PRÁTICO
• VALOR: 6,0 PONTOS
• DATA DE ENTREGA: 04/09/2006


TRABALHO PRÁTICO
ELABORAR A ANÁLISE E O PROJETO DE UM SOFTWARE EM
EQUIPE UTILIZANDO UMA FERRAMENTA CASE, PREVENDO
FUNCIONALIDES WEB.
• ELEMENTOS DO TRABALHO:
• PROPOSTA DE ESPECIFICAÇÃO DE SOFTWARE
(CONFORME DOCUMENTO-MODELO!)

• 1 DIAGRAMA DE CASO DE USO DE NEGÓCIO
• 1 DIAGRAMA DE CASO DE USO
• OS CASOS DE USO MANTER, CONSULTAR e EMITIR RELATÓRIOS DEVEM
SER TODOS PREVISTOS!

• 1 ESPECIFICAÇÃO DO CASO DE USO(PRINCIPAL)
(CONFORME DOCUMENTO-MODELO!)

• ELEMENTOS: ATOR(ES) ; FLUXOS PRINCIPAL, ALTERNATIVOS E DE
EXCEÇÕES; PRÉ-CONDIÇOES E PÓS-CONDIÇÕES;
LISTA DAS CLASSES ENVOLVIDAS; REFERÊNCIAS AOS
CASOS DE USOS RELACIONADOS.

• 1 DIAGRAMA DE CLASSES 8

OO - PARADIGMA ORIENTADO A OBJETOS


3


CONTEXTO
Solucionar problemas existentes no
desenvolvimento de Softwares Complexos
com baixo custo de desenvolvimento e
manutenção
Mundo Real é formado por objetos que se
interagem
Representar esses objetos em um software é
mais natural e permanente do que
representar a sua funcionalidade
(decomposição funcional), pois essa é
mutável



PARADIGMA TRADICIONAL X OO

Procedure Dados Dados
X
Métodos Métodos
Procedure Dados
Y
Dados
Procedure
Z Métodos

Objeto


OO - CONCEITOS
OBJETO
Definição
Qualquer coisa, real ou abstrata, a respeito da
qual armazenamos dados e métodos que os
manipulam
Exemplo: cachorro Bilu, casa do Ricardo, carro da
Ana, etc.
Atributos(c/valores): Métodos:
•Placa = LVY-1234 •Ligar o Motor()
•Proprietário = João •Andar()
•Cor = Vermelha •Freiar()
•Ano = 2002 •Desligar o Motor()
• ... • ...

4

OO - CONCEITOS

CLASSE
Definição
Abstração de um conjunto de objetos similares do
mundo real
Exemplo: cachorro, casa, carro, etc.

Atributos(s/valores): Operações:
•Placa •Ligar o Motor()
•Proprietário •Andar()
•Cor •Freiar()
•Ano •Desligar o Motor()
• ... • ...

OO - CONCEITOS

RELAÇÃO CLASSE x OBJETO
Todo objeto é uma instância de uma
Classe
Todas as instâncias de uma classe têm
valores próprios para os atributos
especificados na classe
Os objetos representados por
determinada classe diferenciam-se
entre si pelos valores de seus atributos


OO - CONCEITOS

CLASSE
Livro

OBJETOS

Bíblia Relatório Dicionário


5

OO - CONCEITOS

CLASSE CASA Nome
Portas Quartos
Salas Localização Atributos
Cozinha Telhado

Reformar Pintar
Limpar Mobiliar Operações

OBJETOS


OO - CONCEITOS



OO - CONCEITOS
HERANÇA
Definição
Mecanismo que permite definir uma nova classe
(subclasse) a partir de uma classe já existente
(superclasse)
Comportamento
Ao se estabelecer uma Especialização (subclasse) de
uma classe, a subclasse herda as características
comuns da superclasse
A subclasse pode adicionar novos atributos e
métodos, como também reescrever métodos herdados
Tipos:
Herança Simples: uma classe é subclasse de somente
uma superclasse
Herança Múltipla: uma classe é subclasse de várias
superclasses
18
Prof. Ricardo Luiz

6

Generalização (Superclasse)
Portas Quartos
Reformar Pintar
Salas Localização
Limpar Mobiliar
Cozinha Telhado

CASA

PRAIA FAVELA MANSÃO
Limpar Piscina
Contratar Criadagem
(Subclasses)
Piscina
Quadras

Especialização
19

Animal superclasse

Selvagem Doméstico subclasses

Hierarquia de Classes
Gato Cão

De Raça Vira-Lata

Objeto Rex Rex
instância da classe Vira-Lata
20

Veículo

Véiculo de Veículo à Veículo
Rodas Motor Aéreo

Bicicleta Caminhão Vapor Avião Planador

Caminhão Caminhão Caminhão
VW Ford GM

21

7

Ex: Sistema de Administração Universitária
Nome, Data de Nasc. RG
Nascer, Comer, Dormir, Morrer
Pessoa

RG (registro)
Cursar Estudante Docente Funcionário

Graduação Pós-Graduação
Herança
Múltipla
Assistente 22

OO - CONCEITOS
ENCAPSULAMENTO DE DADOS
Definição
Os DADOS e os MÉTODOS são empacotados sob um
NOME e podem ser reusados como uma
especificação ou componente de programa
Os atributos de um objeto só podem ser manipulados
pelos próprios métodos do objeto
Vantagens Nome CASA
Segurança de acesso Portas Quartos
aos dados de um objeto
Facilita o reuso de código
Atributos Salas Localização
Cozinha Telhado

Reformar Pintar
Métodos Limpar Mobiliar

23
Prof. Ricardo Luiz

OO - CONCEITOS
POLIMORFISMO (VÁRIAS FORMAS)
Definição
Capacidade de uma mensagem(mecanismo de comunicação
entre os objetos) ser executada de acordo com as características
do objeto que está recebendo o pedido de execução do serviço
(Superclasse) FIGURA

DESENHAR( ) Operação - Definição do Método

(Subclasses) CÍRCULO QUADRADO TRIÂNGULO

Implementações do Método DESENHAR( ) DESENHAR( ) DESENHAR( )

24
Prof. Ricardo Luiz

8



O SOFTWARE NOS DIAS ATUAIS
• COMBUSTÍVEL DOS NEGÓCIOS MODERNOS
• AJUDA A CRIAR, ACESSAR E VISUALIZAR A INFORMAÇÃO
DE FORMAS ANTERIORMENTE INCONCEBÍVEIS
• BOA NOTÍCIA: A ECONOMIA MUNDIAL DEPENDE CADA
VEZ MAIS DO SOFTWARE
• MÁ NOTÍCIA: OS SISTEMAS CRESCEM EM TAMANHO,
COMPLEXIDADE, DISTRIBUIÇÃO E IMPORTÂNCIA MAIS
RÁPIDOS QUE O APRENDIZADO DE DESENVOLVIMENTO




9

A CRISE DO SOFTWARE

Razões para a Crise do Software

Estimativas de calendário e custos
pouco precisos
Produtividade mal controlada
Qualidade baixa
Dificuldade de manutenção


A CRISE DO SOFTWARE

Causas da Crise

Natureza lógica e não física
Proveniente de trabalho de equipe
Ineficiente definição do que o usuário
pretende
Deficiente formação dos técnicos
envolvidos


OS MITOS DO SOFTWARE

Dos Gestores
Possuímos normas, então está tudo
controlado
Dos Usuários
Basta definir em geral
Dos Analistas e Programadores
Quando um programa funciona, então
está pronto


10

CRISE DO SOFTWARE

Conseqüências
Prazos de desenvolvimento não são
cumpridos
31% dos projetos de software não terminam
53% custam 200% do valor original estimado
Empresas e governo americanos gastaram
em 1995, U$ 81 bi em projetos de software
que foram cancelados
FASES CUSTO DE MANUTENÇÃO
DEFINIÇÃO 1x
DESENVOLVIMENTO 1.5 - 6x
MANUTENÇÃO 60 - 100x


SOLUÇÃO PARA A CRISE DO SOFTWARE

Adoção de uma Metodologia de
Desenvolvimento de Software

Rational Unified Process
(Processo Unificado da Rational* Software Corporation)
Empresa fundada em 1981 pelos autores da UML
Grady BOOCH, James RUMBAUGH, Ivar JACOBSON

* Metodologia adquirida pela IBM em 2003. Agora IBM Rational

METODOLOGIA RUP

Práticas adotadas
Desenvolver o software iterativamente
Gerenciar os requisitos
Usar arquiteturas baseadas em
componentes
Modelar visualmente o software
Verificar continuamente a qualidade do
software
Controlar mudanças do software

11

RUP – PRÁTICAS ADOTADAS
1 - Desenvolver o software iterativamente
Baseado no Ciclo de Vida Iterativo e Incremental

Foco da iteração depende da Fase

34

REVISÃO DOS CICLOS DE VIDA

Ciclo de Vida em Cascata (Clássico)
Levantamento de Projetos reais
Requisitos raramente
Análise de seguem o fluxo
Requisitos seqüencial que
Projeto o modelo
propõe
Codificação

O cliente deve ter Testes
paciência. Uma
Implantação
versão executável do
software só fica Manutenção
disponível numa
etapa avançada do
desenvolvimento


2 - Gerenciar os requisitos
Requisito : "uma condição ou capacidade
na qual o sistema deve estar em
conformidade".
Atividades a serem desempenhadas
Analisar o problema
Entender a necessidade do usuário
Definir o sistema
Gerenciar o escopo do projeto
Refinar a definição do sistema
Gerenciar as mudanças nos requisitos
Desenvolvimento por Casos de Uso(UML)

12

3 - Usar arquiteturas baseadas em
componentes
Componentes - grupos de código
coesos e com interfaces bem definidas
que encapsulam seus conteúdos
Vantagens Arquiteturais
Ter o controle intelectual do projeto
Reuso em larga escala
Base para o gerenciamento de projetos



4 - Modelar visualmente o software
Uso de componentes semânticos
(gráficos e textos) para capturar a
complexidade do sistema.
Linguagem utilizada: UML


5 - Verificar continuamente a qualidade do
software
Qualidade dos artefatos bem como das
atividades que os produzem
Qualidade de Produto
Qualidade de Processo
Medindo a Qualidade
Avaliando a Qualidade


13


6 - Controlar mudanças do software
Coordenar atividades e artefatos
Coordenar alterações e releases



Unified Modeling Language
(Linguagem de Modelagem Unificada)
Padronizada pela OMG* - Object Management Group

* OMG – Organismo Internacional Não-Lucrativo da Indústria de
Computadores aberto a novos membros


UML – Unified Modeling Language
Importância da Modelagem (Criar Modelos)
Um modelo é uma simplificação da
realidade.
A modelagem é uma técnica de
engenharia aprovada e bem aceita


14

Importância da Modelagem (Criar Modelos)
Criamos modelos para compreender
melhor o que queremos construir
MODELO OBJETO REAL


O que é ?
Linguagem de modelagem unificada utilizada
para visualizar, especificar, construir e
documentar sistemas Orientados a Objetos.



Características
Visualizar
Ferramenta gráfica que facilita o entendimento do projeto
Afinal : “Uma imagem vale mais do que mil palavras”
Especificar
Ajuda a construir modelos mais precisos
Construir
Seus modelos podem ser diretamente conectados a linguagens de
programação

Documentar
Documenta-se a arquitetura do sistema e seus detalhes


15

Principais Autores
Grady BOOCH

James RUMBAUGH

Ivar JACOBSON



BOOCH RUMBAUGH JACOBSON
OMT - Object Modeling Technique
OOSE -Object Oriented Software Engineering

Histórico da UML


16


Blocos de Construção da UML
O vocabulário da UML abrange três tipos de Blocos de
construção:
1. Itens
2. Relacionamentos
3. Diagramas



1. Itens
Estruturais
Comportamentais
Agrupamento
Anotacionais
2. Relacionamentos
Dependência
Associação
Generalização
Realização


3. Diagramas (9 – vs. 1.4 / 13 vs. 2.0)
Diagramas Estruturais Diagramas Dinâmicos
Classes Casos de Uso
Objetos Atividades
Componentes Estados
Implantação Diagramas de Interação
Pacotes* Seqüências
Estruturas Compostas* Visão Geral*
Temporal*
Comunicação*(Colaboração)
* Novos Diagramas da UML 2.0

17

UML – BLOCOS DE CONSTRUÇÃO

Itens Estruturais
Partes mais estáticas do modelo,
representam os elementos conceituais
ou físicos
Existem 7 tipos de itens estruturais



Itens Estruturais (7)
1. Classes: São descrições como conjunto de objetos

Graficamente:

2. Interface: Coleção de operações que especificam
serviços de uma classe
Graficamente:

3. Colaborações: Definem interações
Graficamente:

4. Caso de uso: É a descrição de um conjunto de ações
Graficamente:



Itens Estruturais (7)
5. Classes ativas: São classes cujos objetos têm um
ou mais processos e, portanto, podem iniciar
atividade de controle

Graficamente:

6. Componentes: São partes físicas e substituíveis
de um sistema
Graficamente:

7. Nó: Elemento físico existente em tempo de
execução
Graficamente:


18


Itens Comportamentais (2)
1. Interação: Abrange um conjunto de mensagens
trocadas entre um conjunto de objetos.
Graficamente: exibir

2. Máquina de estado: Especifica as seqüências de
estados pelas quais os objetos ou interações
passam .
Graficamente:



Item de Agrupamento (1)
1. Pacote: Organização de elementos em grupos

Graficamente:

Item Anotacional (1)
1. Nota: Símbolo para representar restrições e
comentários anexados a um elemento

Graficamente:


Relacionamentos (4)
1. Dependência: Relacionamento semântico entre dois
itens.
Graficamente

2. Associação: Relacionamento estrutural que descreve
um conjunto de ligações.
Graficamente
ASSOCIAÇÃO AGREGAÇÃO COMPOSIÇÃO
3. Generalização: Relacionamento de
especialização/generalização.
Graficamente

4. Realização: Relacionamento semântico entre
classificadores.
Graficamente

19

Diagramas
•O uso de diagramas permite a visualização de
um sistema de vários pontos de vista
•Um diagrama é a representação gráfica de um
conjunto de elementos (Blocos de Construção)
•A UML permite combinar tipos diferentes de
diagramas para focalizar diferentes aspectos de
um sistema, podendo ser criados novos tipos


UML – DIAGRAMAS
Apresentação Rápida
1. Diagrama de Casos de Uso


UML – ALGUNS DIAGRAMAS
2. Diagrama de Atividades


20

3. Diagrama de Seqüências


4. Diagrama de Comunicação(antigo Colaboração)


5. Diagrama de Classes


21

6. Diagrama de Objetos


7. Diagrama de Estados


8. Diagrama de Pacotes


22

9. Diagrama de Componentes


10. Diagrama de Implantação
comunicação

dependência nó


11. Diagrama Temporal


23

12. Diagrama de Estruturas Compostas


13. Diagrama de Visão Geral


UML – DIAGRAMAS
Principais Diagramas
2. Diagrama de Classes


24

CARACTERÍSTICAS DOS DIAGRAMAS
Exibe um conjunto de casos de uso, atores
e seus relacionamentos


DIAGRAMA DE CASOS DE USO
Elementos
Ator
Caso de Uso
Relacionamento


Ator
Necessariamente usuário do sistema
Entidade externa(pessoas, órgãos,
equipamentos ou outros sistemas) que
interage diretamente com o sistema para
conseguir um objetivo desejado
Pode existir o relacionamento de herança
entre atores

Nome do Ator
(Substantivo)

25

Ator
Exemplos:
pessoa órgão equipamento sistema

Cliente Prefeitura Leitora de CEP dos Correios
Gabaritos Web


Ator
Exemplos de Relacionamento(Herança):

Cliente Médico

Cliente Caixa Cliente WEB Oftalmologista Cardiologista
Eletrônico


Caso de Uso
Conjunto de seqüências possíveis das
interações entre o sistema e seus atores
externos, relacionadas a um determinado
objetivo
Na prática, é que o acontece quando o ator
interage com o sistema
Podem existir os relacionamentos de
Herança ou Dependência entre Casos de
Uso

Nome do Caso de Uso(Ação)

26

Caso de Uso
Exemplos:

Cadastrar Pacientes Efetuar Login

Realizar Pedido Emitir Relatório de Vendas


Caso de Uso
Relacionamentos:
Herança A

B

Dependência
Inclusão (Include) <<include>>
A B

Extensão (Extend)
<<extend>>
A B

Caso de Uso
Exemplos de Relacionamento(Herança):

Cadastrar Cadastrar
Pessoa Funcionário

Cadastrar Cadastrar Cadastrar Cadastrar
Pessoa Física Pessoa Jurídica Funcionário Funcionário
Público Terceirizado

27

Caso de Uso
Exemplos de Relacionamento(Dependência):
Inclusão(Include) Extensão(Extend)
<<include>>
<<extend>>
Consultar SPC Pesquisar
Produto
<<extend>>
Cadastrar <<include>>
Cliente Consultar
Realizar Venda Imprimir Orçamento
SERASA
USA PODERÁ USAR


Relacionamento (Ator e Caso de Uso)
Chamado de Associação (de Comunicação)
Uma associação pode ser em:
ambas as direções (sem navegabilidade)
uma direção (com navegabilidade),
indicando o sentido da comunicação

Cadastrar Registrar
Cliente Notas
Secretária Professor Aluno

Exemplo 1: Biblioteca WEB


28

Exemplo 2: Sistema Bancário WEB


CARACTERÍSTICAS DOS DIAGRAMAS
2. Diagrama de Classes (de Entidade)
Apresenta as classes e os
relacionamentos entre elas
Elementos
Classe
Relacionamento


DIAGRAMA DE CLASSES
Estereótipos de Classes
Classe Fronteira (<<boundary>>)
Modelam as interfaces entre sistema e atores

Classe de Controle (<<control>>)
Controlam o fluxo operacional do programa

Classe de Entidade (<<entity>>)
Modelam entidades do mundo real. Criam objetos que
gerenciam dados.


29

DIAGRAMA DE CLASSES
Diagrama de Classes com Estereótipos


DIAGRAMA DE CLASSES
Principais Tipos de Relacionamento
Associação
Significa que há uma ligação entre os objetos das classes
associadas
Uma associação entre Cliente e Conta Corrente significa
que os objetos da classe Cliente estão conectados aos
objetos da classe Conta Corrente
São representados por linhas ligando as classes


DIAGRAMA DE CLASSES
Associação (Continuação)
Multiplicidade
Representa a cardinalidade das associações em um
diagrama de classes
Especifica quantas instâncias de uma classe podem
participar da associação


30

DIAGRAMA DE CLASSES
Multiplicidade
Exemplos:

Classe Associativa


DIAGRAMA DE CLASSES
Classe Associativa
Representa a associação entre classes
Ocorre geralmente quando:
a Multiplicidade entre as classes é maior que 1 em
ambos os lados
existem atributos surgidos a partir da associação

Classe Associativa

DIAGRAMA DE CLASSES
Agregação
É um relacionamento entre o todo e suas partes
Um pequeno losango em branco é desenhado ao lado da
classe que representa o todo
Há uma certa subordinação entre as classes
Relacionamento por referência
O Todo “Nasce” SEM as Partes!


31

DIAGRAMA DE CLASSES
Composição
É um relacionamento entre o todo e suas partes
Um pequeno losango preto é desenhado ao lado da
classe que representa o todo
Relacionamento por valor
O Todo “Nasce” COM as Partes!


DIAGRAMA DE CLASSES
Generalização
Conhecido também como Herança

refere-se a

1


DIAGRAMA DE CLASSES
Papéis nas Associações
A extremidade de uma associação, na conexão
com a classe, é denominada : “o papel que a
classe desempenha na associação”


32

DIAGRAMA DE CLASSES
Navegabilidade nas Associações
Unidirecional

Apenas uma classe conhece a outra
Cliente não tem Pedido tem a
responsabilidade de responsabilidade de
identificar seus pedidos identificar seu Cliente
Bidirecional
As duas classes se “conhecem”
/* em JAVA -------- /* em JAVA --------
Class Cliente { Class Pedido {
Private set peds Private Cliente cli
Public set ObterPedidos( )} Public Cliente ObterCli ( )}

DIAGRAMA DE CLASSES
Atributos e Métodos

Estereótipo <<entity>>
Nome Venda

Atributos -data: date
-status: Integer
-obs: String
-valorTotal: Float
Métodos +calcImposto()
+calcTotal()
-calcSubTotal()
+setCliente(cliente: Cliente)
+inserirItem(item: ItemVenda)


DIAGRAMA DE CLASSES
Visibilidade
Conceito
Como uma classe, atributo ou método
pode se visto e usado por outros
elementos <<entity>>
Tipos Venda
-data: date
Privada (-) -status: Integer
-obs: String
Protegida (#) -valorTotal: Float
de Pacote (~) +calcImposto()
+calcTotal()
Pública (+) -calcSubTotal()


33

DIAGRAMA DE CLASSES
Visibilidade dos Atributos e Métodos
Privada
Somente os objetos da própria classe podem
vê-los
Símbolo: (-) <<entity>>
Venda
-data: date
-status: Integer
Atenção! Regra Geral para Atributos: -obs: String
-valorTotal: Float
Via de Regra, Todos os Atributos de uma +calcImposto()
Classe devem ser Privados !!! +calcTotal()
-calcSubTotal()
-setCliente(cliente: Cliente)
Mas por quê ? -inserirItem(item: ItemVenda)

Resposta: Para Manter o Encapsulamento da Classe!


DIAGRAMA DE CLASSES
Protegida
Somente os objetos da própria classe e das
suas subclasses podem vê-los
Símbolo: (#) <<entity>>
Venda
-data: date
-status: Integer
-obs: String
-valorTotal: Float
+calcImposto()
+calcTotal()
-calcSubTotal()
# setCliente(cliente: Cliente)
#inserirItem(item: ItemVenda)
<<entity>>
Venda Consignada


DIAGRAMA DE CLASSES
de Pacote
Somente os objetos de classes do mesmo
pacote podem vê-los
Símbolo: (~)

Recursos
Humanos Vendas <<entity>>
Venda
<<entity>> -data: date
Cliente -status: Integer
-razaoSocial: String -obs: String
-cpf: String 1 0..* -valorTotal: Float
+getRazaoSocial() +calcImposto()
+setRazaoSocial(razaoSocial: String) +calcTotal()
-calcSubTotal()
~ setCliente(cliente: Cliente)
~inserirItem(item: ItemVenda)


34

DIAGRAMA DE CLASSES
Pública
Todos os objetos de qualquer classe podem
vê-los
Símbolo: (+)

Recursos
Humanos Vendas <<entity>>
Venda
<<entity>> -data: date
Cliente -status: Integer
-razaoSocial: String -obs: String
-cpf: String 1 0..* -valorTotal: Float
+getRazaoSocial() +calcImposto()
+setRazaoSocial(razaoSocial: String) +calcTotal()
-calcSubTotal()
+ setCliente(cliente: Cliente)


DIAGRAMA DE CLASSES
Diagrama de Classes com Atributos e Métodos
<<entity>>
Venda
-data: date
<<entity>> -status: Integer
Cliente -obs: String <<entity>>
-valorTotal: Float Pagamento
-razaoSocial: String
-cpf: String 0..* +calcImposto() 1 -quantia: Float
1 1..*
+getRazaoSocial() +calcTotal() +getQuantia()
+setRazaoSocial(razaoSocial: String) -calcSubTotal()
<<boundary>>
FormVenda
1 <<entity>> <<entity>>
+criarVenda() Cartao Cheque
+gravarVenda() 1..*
-numero: Integer -banco: Integer
-tipo: Integer
<<entity>>
ItemVenda
<<entity>>
Produto 1 0..*
-qtd: Integer <<entity>>
-descricao: String +setQuantidade(qtd: Integer) Dinheiro
+setProduto(produto: Produto)


35

Analise e projetos orientados a objetos

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Analise e projetos orientados a objetos

Mais de Sliedesharessbarbosa

Último

Analise e projetos orientados a objetos