analise e projetos orientados a objetos

1

1

Carga Horária: 32 horas/aula

Análise e Projeto de Sistemas Orientados a Objetos

(Object-Oriented Analysis & Design )

Prof. Ricardo Luiz

– APOO –(OOA&D)

2Prof. Ricardo Luiz

APOO - Análise e Projeto de Sistemas Orientados a Objetos

• 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

EMENTA

3Prof. Ricardo Luiz


• 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.

BIBLIOGRAFIA

2

4Prof. Ricardo Luiz


• 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 unifiedprocess. 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.

BIBLIOGRAFIA

5Prof. Ricardo Luiz


www.wthreex.com/rup/index.htm

www.mundooo.com.br

www.aspercom.com.br

www.cpgei.cefetpr.br/~stad/Apostila%20de%20UML%20CEFET.pdf

https://jude.change-vision.com/jude-web/product/community.html

www.uml.org

LINKS ÚTEIS

6Prof. Ricardo Luiz


• 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

PLANO DE AULA

3

7Prof. Ricardo Luiz


• 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

AVALIAÇÃO

8


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

TRABALHO PRÁTICO

9Prof. Ricardo Luiz


OO - PARADIGMA ORIENTADO A OBJETOS

4

10Prof. Ricardo Luiz



CONTEXTO

Solucionar problemas existentes no desenvolvimento de Softwares Complexoscom baixo custo de desenvolvimento e manutençãoMundo Real é formado por objetos que se interagemRepresentar esses objetos em um software émais natural e permanente do querepresentar a sua funcionalidade(decomposição funcional), pois essa émutável




PARADIGMA TRADICIONAL X OO

Procedure X

Procedure Y

Procedure Z

Dados

Dados

Métodos

Dados

Métodos

Dados

Métodos

Objeto



OO - CONCEITOS

OBJETODefinição

Qualquer coisa, real ou abstrata, a respeito daqual armazenamos dados e métodos que osmanipulam

Exemplo: cachorro Bilu, casa do Ricardo, carro daAna, etc.

Atributos(c/valores):

•Placa = LVY-1234

•Proprietário = João

•Cor = Vermelha

•Ano = 2002

• ...

Métodos:

•Ligar o Motor()

•Andar()

•Freiar()

•Desligar o Motor()

• ...

5



OO - CONCEITOS

CLASSEDefinição

Abstração de um conjunto de objetos similares do mundo real

Exemplo: cachorro, casa, carro, etc.

Atributos(s/valores):

•Placa

•Proprietário

•Cor

•Ano

• ...

Operações:

•Ligar o Motor()

•Andar()

•Freiar()

•Desligar o Motor()

• ...



OO - CONCEITOS

RELAÇÃO CLASSE x OBJETOTodo objeto é uma instância de umaClasseTodas as instâncias de uma classe têmvalores próprios para os atributosespecificados na classeOs objetos representados pordeterminada classe diferenciam-se entre si pelos valores de seus atributos



OO - CONCEITOS

RELAÇÃO CLASSE x OBJETO

DicionárioRelatórioBíblia

LivroCLASSE

OBJETOS

6



OO - CONCEITOS

RELAÇÃO CLASSE x OBJETOCLASSE

OBJETOS

CASA

Portas QuartosSalas LocalizaçãoCozinha Telhado

Reformar PintarLimpar Mobiliar

Nome

Atributos

Operações



OO - CONCEITOS

RELAÇÃO CLASSE x OBJETO



OO - CONCEITOSHERANÇA

Definição Mecanismo que permite definir uma nova classe(subclasse) a partir de uma classe já existente(superclasse)

ComportamentoAo se estabelecer uma Especialização (subclasse) de uma classe, a subclasse herda as característicascomuns da superclasseA subclasse pode adicionar novos atributos e métodos, como também reescrever métodos herdados

Tipos:Herança Simples: uma classe é subclasse de somenteuma superclasseHerança Múltipla: uma classe é subclasse de váriassuperclasses

7

19

CASA



PRAIA FAVELA MANSÃOLimpar PiscinaContratar CriadagemPiscinaQuadras

(Superclasse)

(Subclasses)

Especialização

Generalização

20

Animal

Selvagem Doméstico

Gato Cão

De Raça Vira-Lata

Rex

superclasse

subclasses

Objeto Rexinstância da classe Vira-Lata

Hierarquia de Classes

21

Veículo

Véiculo de Rodas

Veículo à Motor

Veículo Aéreo

Bicicleta Caminhão Vapor PlanadorAvião

Caminhão VW

CaminhãoFord

Caminhão GM


8

22

Ex: Sistema de Administração Universitária

Pessoa

Estudante Docente Funcionário

Graduação Pós-Graduação

Assistente

HerançaMúltipla

Nome, Data de Nasc. RGNascer, Comer, Dormir, Morrer

RG (registro)Cursar




OO - CONCEITOSENCAPSULAMENTO 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 programaOs atributos de um objeto só podem ser manipuladospelos próprios métodos do objeto

VantagensSegurança de acesso aos dados de um objetoFacilita o reuso de código

CASA



Nome

Atributos

Métodos



OO - CONCEITOSPOLIMORFISMO (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

Operação - Definição do Método

FIGURA

DESENHAR( )

CÍRCULO

DESENHAR( )

QUADRADO

DESENHAR( )

TRIÂNGULO

DESENHAR( )

(Superclasse)

(Subclasses)

Implementações do Método

9





• 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

O SOFTWARE NOS DIAS ATUAIS



10



A CRISE DO SOFTWARE

Razões para a Crise do Software

Estimativas de calendário e custos pouco precisosProdutividade mal controladaQualidade baixaDificuldade de manutenção



A CRISE DO SOFTWARE

Causas da Crise

Natureza lógica e não físicaProveniente de trabalho de equipeIneficiente definição do que o usuário pretendeDeficiente formação dos técnicos envolvidos



OS MITOS DO SOFTWARE

Dos GestoresPossuímos normas, então está tudo controlado

Dos UsuáriosBasta definir em geral

Dos Analistas e ProgramadoresQuando um programa funciona, então está pronto

11



CRISE DO SOFTWARE

ConseqüênciasPrazos 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 1 xDESENVOLVIMENTO 1.5 - 6xMANUTENÇÃ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 iterativamenteGerenciar os requisitosUsar arquiteturas baseadas em componentesModelar visualmente o softwareVerificar continuamente a qualidade do softwareControlar mudanças do software

12

34


RUP – PRÁTICAS ADOTADAS1 - Desenvolver o software iterativamente

Baseado no Ciclo de Vida Iterativo e Incremental

Foco da iteração depende da Fase



REVISÃO DOS CICLOS DE VIDA

Ciclo de Vida em Cascata (Clássico)Levantamento de Requisitos

Análise de Requisitos

Projeto

Codificação

Testes

Implantação

Manutenção

Projetos reais raramente seguem o fluxo seqüencial que o modelo propõe

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



RUP – PRÁTICAS ADOTADAS

2 - Gerenciar os requisitosRequisito : "uma condição ou capacidade na qual o sistema deve estar em conformidade".Atividades a serem desempenhadas

Analisar o problemaEntender a necessidade do usuárioDefinir o sistemaGerenciar o escopo do projetoRefinar a definição do sistemaGerenciar as mudanças nos requisitos

Desenvolvimento por Casos de Uso(UML)

13




Componentes - grupos de código coesos e com interfaces bem definidas que encapsulam seus conteúdos

Vantagens ArquiteturaisTer o controle intelectual do projetoReuso em larga escalaBase para o gerenciamento de projetos

3 - Usar arquiteturas baseadas em componentes




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



RUP – PRÁTICAS ADOTADAS5 - Verificar continuamente a qualidade do software

Qualidade dos artefatos bem como das atividades que os produzem

Qualidade de ProdutoQualidade de ProcessoMedindo a QualidadeAvaliando a Qualidade

14




6 - Controlar mudanças do softwareCoordenar atividades e artefatosCoordenar 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

15




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ísticasVisualizar

Ferramenta gráfica que facilita o entendimento do projetoAfinal : “Uma imagem vale mais do que mil palavras”

EspecificarAjuda a construir modelos mais precisos

ConstruirSeus modelos podem ser diretamente conectados a linguagens de programação

DocumentarDocumenta-se a arquitetura do sistema e seus detalhes

16




Principais Autores

Grady BOOCH

James RUMBAUGH

Ivar JACOBSON




BOOCH RUMBAUGH JACOBSONOMT - Object Modeling Technique

OOSE -Object Oriented Software Engineering




Histórico da UML

17




Blocos de Construção da UMLO vocabulário da UML abrange três tipos de Blocos de

construção:

1. Itens

2. Relacionamentos

3. Diagramas




Blocos de Construção da UML1. Itens

EstruturaisComportamentaisAgrupamentoAnotacionais

2. RelacionamentosDependênciaAssociaçãoGeneralizaçãoRealização



UML – Unified Modeling LanguageBlocos de Construção da UML3. Diagramas (9 – vs. 1.4 / 13 vs. 2.0)Diagramas Estruturais Diagramas DinâmicosClassesObjetosComponentesImplantaçãoPacotes*Estruturas Compostas*

Casos de UsoAtividadesEstados

Diagramas de InteraçãoSeqüênciasVisão Geral*Temporal*Comunicação*(Colaboração)

* Novos Diagramas da UML 2.0

18



UML – BLOCOS DE CONSTRUÇÃO

Itens EstruturaisPartes mais estáticas do modelo,

representam os elementos conceituaisou físicos

Existem 7 tipos de itens estruturais

53

1. Classes: São descrições como conjunto de objetos

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

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

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

Prof. Ricardo Luiz



Itens Estruturais (7)

Graficamente:

Graficamente:

Graficamente:

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

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

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

Graficamente:

Graficamente:

Graficamente:

19




Itens Comportamentais (2)1. Interação: Abrange um conjunto de mensagens

trocadas entre um conjunto de objetos.

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

Graficamente: exibir

Graficamente:




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

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

Graficamente:

Item Anotacional (1)

Graficamente:

57

1. Dependência: Relacionamento semântico entre dois itens.

2. Associação: Relacionamento estrutural que descreve um conjunto de ligações.

3. Generalização: Relacionamento de especialização/generalização.

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

Prof. Ricardo Luiz



Relacionamentos (4)

Graficamente

Graficamente

GraficamenteCOMPOSIÇÃOAGREGAÇÃOASSOCIAÇÃO

Graficamente

20




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 – DIAGRAMASApresentação Rápida1. Diagrama de Casos de Uso



UML – ALGUNS DIAGRAMASApresentação Rápida2. Diagrama de Atividades

21



UML – ALGUNS DIAGRAMASApresentação Rápida3. Diagrama de Seqüências



UML – ALGUNS DIAGRAMASApresentação Rápida4. Diagrama de Comunicação(antigo Colaboração)



UML – ALGUNS DIAGRAMASApresentação Rápida5. Diagrama de Classes

22



UML – ALGUNS DIAGRAMASApresentação Rápida6. Diagrama de Objetos



UML – ALGUNS DIAGRAMASApresentação Rápida7. Diagrama de Estados



UML – ALGUNS DIAGRAMASApresentação Rápida8. Diagrama de Pacotes

23



UML – ALGUNS DIAGRAMASApresentação Rápida9. Diagrama de Componentes



UML – ALGUNS DIAGRAMASApresentação Rápida10. Diagrama de Implantação

nódependência

comunicação



UML – ALGUNS DIAGRAMASApresentação Rápida11. Diagrama Temporal

24



UML – ALGUNS DIAGRAMASApresentação Rápida12. Diagrama de Estruturas Compostas



UML – ALGUNS DIAGRAMASApresentação Rápida13. Diagrama de Visão Geral



UML – DIAGRAMAS

Principais Diagramas1. Diagrama de Casos de Uso

2. Diagrama de Classes

25

73

Exibe um conjunto de casos de uso, atores e seus relacionamentos

Prof. Ricardo Luiz


CARACTERÍSTICAS DOS DIAGRAMAS

1. Diagrama de Casos de Uso

74

AtorCaso de UsoRelacionamento

Prof. Ricardo Luiz


DIAGRAMA DE CASOS DE USO

Elementos

75

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

Prof. Ricardo Luiz



Ator

Nome do Ator (Substantivo)

26

76

Exemplos:

Prof. Ricardo Luiz



Ator

Cliente Prefeitura Leitora de Gabaritos

CEP dos Correios Web

pessoa órgão equipamento sistema

77

Exemplos de Relacionamento(Herança):

Prof. Ricardo Luiz



Ator

Cliente

Cliente Caixa Eletrônico

Cliente WEB

Médico

Oftalmologista Cardiologista

78

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

Prof. Ricardo Luiz



Caso de Uso

Nome do Caso de Uso(Ação)

27

79

Exemplos:

Prof. Ricardo Luiz



Caso de Uso

Cadastrar Pacientes Efetuar Login

Realizar Pedido Emitir Relatório de Vendas

80

Relacionamentos:Herança

DependênciaInclusão (Include)

Extensão (Extend)

Prof. Ricardo Luiz



Caso de Uso

B

A

A B<<include>>

A B<<extend>>

81

Exemplos de Relacionamento(Herança):

Prof. Ricardo Luiz



Caso de Uso

Cadastrar Pessoa Física

Cadastrar Pessoa Jurídica

Cadastrar Pessoa

Cadastrar Funcionário

Público

Cadastrar Funcionário Terceirizado

Cadastrar Funcionário

28

82

Exemplos de Relacionamento(Dependência):

Prof. Ricardo Luiz



Caso de Uso

Consultar SPC

Cadastrar Cliente

Pesquisar Produto

Realizar VendaConsultar SERASA

<<include>>

<<include>>

<<extend>>

Imprimir Orçamento

<<extend>>

Inclusão(Include) Extensão(Extend)

PODERÁ USARUSA

83

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

Prof. Ricardo Luiz



Relacionamento (Ator e Caso de Uso)

SecretáriaCadastrar

Cliente ProfessorRegistrar

NotasAluno




Exemplo 1: Biblioteca WEB

29




Exemplo 2: Sistema Bancário WEB



CARACTERÍSTICAS DOS DIAGRAMAS

2. Diagrama de Classes (de Entidade)

Apresenta as classes e os relacionamentos entre elasElementos

ClasseRelacionamento

87

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.

Prof. Ricardo Luiz


DIAGRAMA DE CLASSES

Estereótipos de Classes

30



DIAGRAMA DE CLASSES

Diagrama de Classes com Estereótipos

89

AssociaçãoSignifica que há uma ligação entre os objetos das classes associadasUma associação entre Cliente e Conta Corrente significa que os objetos da classe Cliente estão conectados aos objetos da classe Conta CorrenteSão representados por linhas ligando as classes


DIAGRAMA DE CLASSESPrincipais Tipos de Relacionamento

Prof. Ricardo Luiz

90

Associação (Continuação)Multiplicidade

Representa a cardinalidade das associações em um diagrama de classesEspecifica quantas instâncias de uma classe podem participar da associação



Prof. Ricardo Luiz

31

91

Associação (Continuação)Multiplicidade

Exemplos:



Prof. Ricardo Luiz

Classe Associativa

92

Associação (Continuação)Classe Associativa

Representa a associação entre classesOcorre geralmente quando:

a Multiplicidade entre as classes é maior que 1 em ambos os ladosexistem atributos surgidos a partir da associação



Prof. Ricardo LuizClasse Associativa

93

AgregaçãoÉ um relacionamento entre o todo e suas partesUm pequeno losango em branco é desenhado ao lado da classe que representa o todoHá uma certa subordinação entre as classesRelacionamento por referênciaO Todo “Nasce” SEM as Partes!

Prof. Ricardo Luiz


DIAGRAMA DE CLASSES

Principais Tipos de Relacionamento

32

94

ComposiçãoÉ um relacionamento entre o todo e suas partesUm pequeno losango preto é desenhado ao lado da classe que representa o todoRelacionamento por valorO Todo “Nasce” COM as Partes!

Prof. Ricardo Luiz


DIAGRAMA DE CLASSES


95

GeneralizaçãoConhecido também como Herança

Prof. Ricardo Luiz


DIAGRAMA DE CLASSES


refere-se a

1

96

A extremidade de uma associação, na conexão com a classe, é denominada : “o papel que a classe desempenha na associação”

Prof. Ricardo Luiz


DIAGRAMA DE CLASSES

Papéis nas Associações

33



DIAGRAMA DE CLASSES

Cliente não tem responsabilidade de

identificar seus pedidos

Navegabilidade nas Associações

Pedido tem a responsabilidade de

identificar seu Cliente

/* em JAVA --------Class Cliente {Private set pedsPublic set ObterPedidos( )}

/* em JAVA --------Class Pedido {Private Cliente cliPublic Cliente ObterCli ( )}

Unidirecional

Apenas uma classe conhece a outra

As duas classes se “conhecem”

Bidirecional



DIAGRAMA DE CLASSESAtributos e Métodos

Venda<<entity>>

-data: date-status: Integer-obs: String-valorTotal: Float

+calcImposto()+calcTotal()-calcSubTotal()+setCliente(cliente: Cliente)+inserirItem(item: ItemVenda)

EstereótipoNome

Atributos

Métodos



DIAGRAMA DE CLASSESVisibilidade

ConceitoComo uma classe, atributo ou método pode se visto e usado por outros elementos

TiposPrivada (-)Protegida (#)de Pacote (~)Pública (+)

Venda<<entity>>



34



DIAGRAMA DE CLASSESVisibilidade dos Atributos e Métodos

PrivadaSomente os objetos da própria classe podem vê-losSímbolo: (-)

Via de Regra, Todos os Atributos de uma Classe devem ser Privados !!!

Atenção! Regra Geral para Atributos:

Venda<<entity>>


+calcImposto()+calcTotal()-calcSubTotal()-setCliente(cliente: Cliente)-inserirItem(item: ItemVenda)Mas por quê ?

Resposta: Para Manter o Encapsulamento da Classe!




ProtegidaSomente os objetos da própria classe e das suas subclasses podem vê-losSímbolo: (#)

Venda<<entity>>


+calcImposto()+calcTotal()-calcSubTotal()# setCliente(cliente: Cliente)#inserirItem(item: ItemVenda)

Venda Consignada<<entity>>




de PacoteSomente os objetos de classes do mesmo pacote podem vê-losSímbolo: (~)

Venda<<entity>>

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

Cliente<<entity>>

-razaoSocial: String-cpf: String

+getRazaoSocial()+setRazaoSocial(razaoSocial: String)

0..*1

Recursos Humanos Vendas

35




PúblicaTodos os objetos de qualquer classe podem vê-losSímbolo: (+)

Venda<<entity>>

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

Cliente<<entity>>



0..*1

Recursos Humanos Vendas



DIAGRAMA DE CLASSESDiagrama de Classes com Atributos e Métodos

Cliente<<entity>>



Venda<<entity>>



0..*1

Pagamento<<entity>>

-quantia: Float

+getQuantia()

Dinheiro<<entity>>

Cheque<<entity>>

-banco: Integer

Cartao<<entity>>

-numero: Integer-tipo: Integer

1..*1

ItemVenda<<entity>>

-qtd: Integer

+setQuantidade(qtd: Integer)+setProduto(produto: Produto)

1

1..*

FormVenda<<boundary>>

+criarVenda()+gravarVenda()

Produto<<entity>>

-descricao: String

1 0..*

analise e projetos orientados a objetos

Education