SlideShare uma empresa Scribd logo
Introdução à Análise Orientada a Objetos Prof. Ariovaldo Dias de Oliveira Parte 3
Solução da Atividade 2 Segue... class Produto { protected int código; protected String descrição; protected int setor; protected double preço; Produto (int código, String descrição, int setor, double preço) { this.código = código; this.descrição = descrição; this.setor = setor; this.preço = preço; } Produto (int código, String descrição, double preço) { this.código = código; this.descrição = descrição; this.preço = preço; this.setor = 3; }
Segue... int getCódigo( ) { return this.código; } String getDescrição() { return this.descrição; } int getSetor( ) { return this.setor; } double getPreço( ) { return this.preço; } double valorICMS ( ) { return this.preço * 0.15; } }
Segue... class Alimento extends Produto { private String codVigilância; Alimento (int código, String descrição, double preço, String codVigilância) { super (código, descrição, 1, preço); this.codVigilância = codVigilância; } String getCodVigilância() { return this.codVigilância; } double valorICMS () { String duasprimeiras = (this.codVigilância.substring(0,2)); if (duasprimeiras.equals ("55")) { return this.preço * 0.1; } else { return this.preço * 0.2; } } }
class Atividade2 { public static void main (String args [ ]) { Produto prod1 = new Produto (123, "Sabonete", 2, 100); Produto prod2 = new Produto (456, "Calça jeans", 200.0); Alimento prod3 = new Alimento (789, "Arroz", 300, "55A54BR"); System.out.println(" "); System.out.println("produto 1 código = " + prod1.getCódigo()); System.out.println("produto 1 descrição = " + prod1.getDescrição()); System.out.println("produto 1 setor = " + prod1.getSetor()); System.out.println("produto 1 preço = " + prod1.getPreço()); System.out.println("produto 1 ICMS = " + prod1.valorICMS()); System.out.println(" "); System.out.println("produto 2 código = " + prod2.getCódigo()); System.out.println("produto 2 descrição = " + prod2.getDescrição()); System.out.println("produto 2 setor = " + prod2.getSetor()); System.out.println("produto 2 preço = " + prod2.getPreço()); System.out.println("produto 2 ICMS = " + prod2.valorICMS()); System.out.println(" "); System.out.println("produto 3 código = " + prod3.getCódigo()); System.out.println("produto 3 descrição = " + prod3.getDescrição()); System.out.println("produto 3 setor = " + prod3.getSetor()); System.out.println("produto 3 preço = " + prod3.getPreço()); System.out.println("produto 3 cod vigilância  = " + prod3.getCodVigilância()); System.out.println("produto 3 ICMS = " + prod3.valorICMS()); } } Segue...
OBS. Quanto ao valor de ICMS, alguém poderia pensar que ele deveria ser um atributo do Produto, mas é melhor não ser. Veja o texto abaixo (James Rumbaugh): “ Durante a modelagem, é útil distinguir operações que têm efeitos colaterais das que apenas calculam um valor funcional sem modificar qualquer objeto. O último tipo de operação é denominado consulta. As consultas sem argumentos além do objeto-alvo podem ser encaradas como  atributos derivados .Por exemplo, a largura de um quadro pode ser calculada pelas posições de seus lados.  Um atributo derivado é como um atributo que seja uma propriedade do próprio objeto e seu cálculo não modifica o estado do objeto. Em muitos casos, um objeto tem um conjunto de atributos cujos valores são inter-relacionados e de onde apenas um número fixo de valores pode ser escolhido de forma independente. Um modelo de objetos normalmente deve fazer distinção entre atributos básicos independentes e atributos derivados dependentes.”
UML ,[object Object]
UML ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
UML  Diagrama de Classes ,[object Object]
Exemplo de Diagrama de Classes Funcionário +bonifica (valor: double ): +demite ( ): +getSalário ( ): double Gerente +nome:  String +departamento:  String  # salário:  double +admissão:  String +rg:  String +ativo:  boolean +senha:  int +autentica (senha: int): boolean
Para relacionar Classes usa-se as seguintes nota ç ões:
Em UML,  Associações  são representadas como linhas conectando as classes participantes do relacionamento, e podem também mostrar a regra e a multiplicidade de cada um dos participantes. A multiplicidade é exibida como um intervalo [min...máx] de valores não negativos. Um asterisco (*) no lado máximo representa infinito.  Diagrama de Classes
A  Herança  é um dos conceitos fundamentais da programação orientada por objetos, nos quais uma classe ganha todos os atributos e operações da classe que herda, podendo sobrepor ou modificar algumas delas, assim como adicionar mais atributos ou operações próprias. EM UML, uma associação Generalização entre duas classes coloca-as numa hierarquia representando o conceito de Herança de uma classe derivada sob uma classe base. Em UML,  Herança  é representada por uma linha conectando duas classes, com uma seta no lado da classe base Diagrama de Classes
Diagrama de Classes Dependência  se define quando uma classe utiliza outra como parâmetro de uma de suas operações.  A dependência entre classes indica que os objetos de uma classe usam serviços dos objetos de outra classe. Em UML,  Dependência  são representadas por uma linha pontilhada conectando duas classes, com uma seta no lado da classe base
Diagrama de Classes Agregações  são um tipo especial de associação no qual as duas classes participantes não possuem nível igual, mas fazem um relacionamento todo-parte. Uma Agregação descreve como a classe que possui a regra do todo, é composta (tem) de outras classes, que possuem a regra das partes. Para  Agregações , a classe que age como o todo sempre tem uma multiplicidade de um. São representadas por uma associação que mostra um losango vazado no lado do todo.
Diagrama de Classes Composições  são associações que representam agregações  muito fortes . Isto significa que  Composições  formam relacionamentos todo-parte também, mas o relacionamento é tão forte que as partes não pode existir independentes. Elas existem somente dentro do todo, e se o todo é destruído as partes morrem também. Em UML, Composições são representadas por um losango sólido no lado do todo
Diagrama de Classes Quando usar Associação Simples, Agregação e Composição? 1) Associação simples :  -estabelece uma relação  semântica estrutural  entre classes.  Ex: uma Pessoa trabalha para uma Companhia, uma Companhia tem vários Escritórios, etc.  2) Agregação :  -estabelece uma relação  todo-parte  entre classes, sendo que a parte  pode existir  sem o todo.  Ex: Carro e Roda. Uma Roda é parte de um Carro, porém pode a Roda existe por si só fora do Carro. Você pode por exemplo remover a roda de um carro para colocar em outro.  3) Composição :  -estabelece uma relação  todo-parte  entre classes, sendo que a parte  NÃO existe  sem o todo.  Ex: Pedido e Itens de Pedido. Se você destruir o Pedido, os Itens são destruídos junto, eles não tem sentido se não houver um Pedido.   Em http://www.guj.com.br/java/85835-uml---diagrama-de-classes-composicao-x-agregacao
Diagrama de Classes Quando usar Associação Simples, Agregação e Composição?  1 - Se eu "deletar" o A, terei que "deletar" também o B ?  Sim = composição  Não = pode ser agregação ou nada... goto pergunta 2  Exemplo: pedido e compras... um pedido pode ter várias compras, mas se eu deletar o pedido, preciso deletar as compras (não faz sentido eu ter um objeto compra sem que ele esteja em nenhum pedido... sua única razão de existir é "compor" um pedido).  2 - O objeto B tem alguma utilidade sozinho ?  Sim = associação comum  Não = agregação  Exemplo: carro e rodas... se eu deletar um carro, não preciso deletar suas rodas, pois elas podem servir pra outro carro. Isso me fez vir para a pergunta 2, porém uma roda tem utilidade sozinha ? Geralmente não, ela serve sempre para "agregar" uma funcionalidade a outro objeto, como a funcionalidade de andar ao carro (ou a um outro veículo qualquer), ou até mesmo a funcionalidade para crianças sentarem em um "balanço de árvore", etc....  O caso de composição é o mais claro, agora o de agregação muitas vezes vai da interpretação do analista, pois alguém poderia contestar que uma roda tem sim uma utilidade sozinha para algum caso bizarro que ele observou, ou que existe no "mundo particular dele".  Em http://www.guj.com.br/java/85835-uml---diagrama-de-classes-composicao-x-agregacao
UML  Diagramas de Caso de Uso ,[object Object],[object Object]
UML  Diagramas de Caso de Uso Componentes: Ator  – é o papel exercido por um usuário, processo ou outro sistema, que irá interagir com um ou vários casos de uso enviando e recebendo mensagens. Os nomes dos atores refletem o papel que um usuário desempenha no sistema.
UML  Diagramas de Caso de Uso Componentes: Caso de Uso  – representa uma funcionalidade completa do sistema, formado por uma sequência de ações que irá gerar um resultado para um ou mais atores. Cada caso de uso possui uma história descritiva das ações que ele realizará, seus métodos de entrada e saída, e as informações que retornará para o ator. Lembrando que o principal foco do caso de uso é dizer O QUE o sistema faz, e não COMO faz.
UML  Diagramas de Caso de Uso Relacionamento simples  – representado por uma linha sólida conectando o ator ao caso de uso o qual ele interage. A linha indica que o relacionamento é bidirecional, o ator envia e recebe informações do caso de uso; pode também ser unidirecional, o ator só envia ou recebe informações. É o único relacionamento exitente entre atores e cados de uso
UML  Diagramas de Caso de Uso Relacionamento de inclusão (include)  – ocorre quando um caso de uso precisa dos recursos de outro, desejamos reduzir a complexidade de um caso de uso ou evitar repetições. É representado por uma seta tracejada rotulada com a palavra  << include >>. A seta aponta para o caso de uso solicitado
UML  Diagramas de Caso de Uso Relacionamento de extensão (extends)  – ocorre quando um caso de uso precisa de recursos de outro, não sendo vitais para a realização do mesmo. Em outras palavras, um caso de uso pode usar os recursos de outro, não sendo obrigatório esse uso. É representado por uma seta tracejada rotulada com a palavra  << extends >>. A seta aponta para o caso de uso solicitante.
UML  Diagramas de Caso de Uso Generalização  – indica que temos especializações de um ator ou caso de uso, indicando comportamentos específicos. Ou seja, posso ter atores especializados para um ou mais casos de uso, assim como casos de uso especializados para uma ou mais tarefas no sistema. É representado por uma seta com ponta sem preenchimento que aponta para o ator ou caso de uso base.
UML  Diagramas de Caso de Uso Exemplo :  temos um sistema de controle de estoque. O funcionário renova o estoque dos produtos quando ele recebe mais produtos do fornecedor e o sistema lhe informa do estoque baixo. O gerente cuida da geração dos relatórios que podem ser usados na auditoria da fiscalização. Percebe-se que os casos de uso estão dentro de um retângulo, que representa a fronteira do sistema. Os casos de uso externos ao retângulo não farão parte do desenvolvimento do sistema. Podemos também incluir notas informativas para esclarecer certos papéis e relacionamentos, como é o caso de “Renovar estoque”.
UML  Diagramas de Caso de Uso Após elaborado o Diagrama de Caso de Uso, parte-se para a  descrição do caso de uso : Número do caso de uso UC001 Nome do caso de uso Renovar estoque Ator(es) Funcionário Descrição Tem por objetivo renovar a quantidade de produtos informando o quantitativo recebido pelo fornecedor. Pré-condição O funcionário recebeu os novos produtos do fornecedor e o sistema informe que o estoque está baixo. Pós-condição Produto é liberado para ser vendido. Fluxo principal ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Fluxo alternativo Não tem. Exceções Nota fiscal não encontrada - Sistema informa que a nota fiscal não foi encontrada. Estoque continua em baixa - A soma de produtos em estoque com os recebidos é menor que o mínimo estabelecido. Sistema continua a informar estoque em baixa. Inclusão (includes) UC002 – Fornecer produtos; UC003 – Informar estoque baixo. Extensões (extends) Não tem. Regras de negócio Soma dos itens recebidos com os itens em estoque é maior que estoque mínimo estabelecido.
UML  Diagramas de Sequência ,[object Object]
Exemplo de Diagrama de Sequência
UML  Outros Diagramas ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Tecnologias de Implementação ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Atividade 4 Suponha que você é o responsável para a implementação de Informática em uma pequena empresa. Seu trabalho começa por entrevistas com os envolvidos, para saber exatamente as necessidades da empresa, e onde e como a Informática pode ajudar.  Levando-se em conta as costumeiras restrições orçamentária, você, juntamente com seu gerente, decidem por começar pela parte onde pode-se obter mais rapidamente algum resultado positivo.  Sua formação profissional está voltada para  Orientação a Objetos  e você realmente acredita que o paradigma OO é o melhor que se tem no momento.  Após algum tempo de trabalho, você já tem pronto um levantamento (baseado em OO) das classes envolvidas e seus relacionamentos. Também já preparou o  Diagrama de Classes ,  Diagrama de Casos de Uso  e  Diagrama de Sequência .  Hoje é o dia de apresentar este material para o gerente e equipe que trabalhará com você no desenvolvimento do Sistema.  Segue...
Atividade 4 ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Referências ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]

Mais conteúdo relacionado

Mais procurados

Aula 02 - UML e Padrões de Projeto
Aula 02 - UML e Padrões de ProjetoAula 02 - UML e Padrões de Projeto
Aula 02 - UML e Padrões de Projeto
Vinícius de Paula
 
Resumo diagramas de classes
Resumo diagramas de classesResumo diagramas de classes
Resumo diagramas de classes
Marco Coelho
 
Introdução à análise orientada a objetos parte 2
Introdução à análise orientada a objetos parte 2Introdução à análise orientada a objetos parte 2
Introdução à análise orientada a objetos parte 2
irenescotolo
 
07 diagrama de classes de análise
07  diagrama de classes de análise07  diagrama de classes de análise
07 diagrama de classes de análise
Filipe Soares
 
Uml
UmlUml
Uml
lcbj
 
Principais diagramas da UML
Principais diagramas da UMLPrincipais diagramas da UML
Principais diagramas da UML
Jéssica Nathany Carvalho Freitas
 
Astah
AstahAstah
Modelagem de Sistemas de Informação 08 - Diagrama de Classes
Modelagem de Sistemas de Informação 08 - Diagrama de ClassesModelagem de Sistemas de Informação 08 - Diagrama de Classes
Modelagem de Sistemas de Informação 08 - Diagrama de Classes
Danielle Ballester, PMP,PSM,SFC,SDC,SMC,SPOC,SCT
 
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. CarvalhoAula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
Rudson Kiyoshi Souza Carvalho
 
Curso Básico de UML
Curso Básico de UMLCurso Básico de UML
Curso Básico de UML
João Carlos da Silva Junior
 
04 modelagem classes
04 modelagem classes04 modelagem classes
04 modelagem classes
josejunior89
 
Mvc
MvcMvc
Mvc
lcbj
 
Introdução à análise orientada a objetos parte 1
Introdução à análise orientada a objetos parte 1Introdução à análise orientada a objetos parte 1
Introdução à análise orientada a objetos parte 1
ariovaldodias
 
UML - Criando Diagramas Eficientes
UML - Criando Diagramas EficientesUML - Criando Diagramas Eficientes
UML - Criando Diagramas Eficientes
Rodrigo Cascarrolho
 
Modelagem de casos de uso e diagramas de sequência
Modelagem de casos de uso e diagramas de sequênciaModelagem de casos de uso e diagramas de sequência
Modelagem de casos de uso e diagramas de sequência
Jorge Linhares
 
SCJA
SCJASCJA
Java8
Java8Java8
Java programação orientada a objetos
Java   programação orientada a objetosJava   programação orientada a objetos
Java programação orientada a objetos
Paulo Carvalho
 
Aula 03 - UML e Padrões de Projeto
Aula 03 - UML e Padrões de ProjetoAula 03 - UML e Padrões de Projeto
Aula 03 - UML e Padrões de Projeto
Vinícius de Paula
 
Revisão 1º bimestre - Casos de Usos e Classes
Revisão 1º bimestre - Casos de Usos e ClassesRevisão 1º bimestre - Casos de Usos e Classes
Revisão 1º bimestre - Casos de Usos e Classes
Maria Alice Jovinski
 

Mais procurados (20)

Aula 02 - UML e Padrões de Projeto
Aula 02 - UML e Padrões de ProjetoAula 02 - UML e Padrões de Projeto
Aula 02 - UML e Padrões de Projeto
 
Resumo diagramas de classes
Resumo diagramas de classesResumo diagramas de classes
Resumo diagramas de classes
 
Introdução à análise orientada a objetos parte 2
Introdução à análise orientada a objetos parte 2Introdução à análise orientada a objetos parte 2
Introdução à análise orientada a objetos parte 2
 
07 diagrama de classes de análise
07  diagrama de classes de análise07  diagrama de classes de análise
07 diagrama de classes de análise
 
Uml
UmlUml
Uml
 
Principais diagramas da UML
Principais diagramas da UMLPrincipais diagramas da UML
Principais diagramas da UML
 
Astah
AstahAstah
Astah
 
Modelagem de Sistemas de Informação 08 - Diagrama de Classes
Modelagem de Sistemas de Informação 08 - Diagrama de ClassesModelagem de Sistemas de Informação 08 - Diagrama de Classes
Modelagem de Sistemas de Informação 08 - Diagrama de Classes
 
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. CarvalhoAula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
 
Curso Básico de UML
Curso Básico de UMLCurso Básico de UML
Curso Básico de UML
 
04 modelagem classes
04 modelagem classes04 modelagem classes
04 modelagem classes
 
Mvc
MvcMvc
Mvc
 
Introdução à análise orientada a objetos parte 1
Introdução à análise orientada a objetos parte 1Introdução à análise orientada a objetos parte 1
Introdução à análise orientada a objetos parte 1
 
UML - Criando Diagramas Eficientes
UML - Criando Diagramas EficientesUML - Criando Diagramas Eficientes
UML - Criando Diagramas Eficientes
 
Modelagem de casos de uso e diagramas de sequência
Modelagem de casos de uso e diagramas de sequênciaModelagem de casos de uso e diagramas de sequência
Modelagem de casos de uso e diagramas de sequência
 
SCJA
SCJASCJA
SCJA
 
Java8
Java8Java8
Java8
 
Java programação orientada a objetos
Java   programação orientada a objetosJava   programação orientada a objetos
Java programação orientada a objetos
 
Aula 03 - UML e Padrões de Projeto
Aula 03 - UML e Padrões de ProjetoAula 03 - UML e Padrões de Projeto
Aula 03 - UML e Padrões de Projeto
 
Revisão 1º bimestre - Casos de Usos e Classes
Revisão 1º bimestre - Casos de Usos e ClassesRevisão 1º bimestre - Casos de Usos e Classes
Revisão 1º bimestre - Casos de Usos e Classes
 

Semelhante a Introdução à análise orientada a objetos parte 3

Aula 5 uml1 (1)
Aula 5   uml1 (1)Aula 5   uml1 (1)
Aula 5 uml1 (1)
Tiago Vizoto
 
Trabalho de análise e projeto 2
Trabalho de análise e projeto 2Trabalho de análise e projeto 2
Trabalho de análise e projeto 2
Meire Dos Santos Aguiar
 
Integração de Tecnologias
Integração de TecnologiasIntegração de Tecnologias
Integração de Tecnologias
elliando dias
 
Java7
Java7Java7
Aula-04-UML.pptx
Aula-04-UML.pptxAula-04-UML.pptx
Aula-04-UML.pptx
rubens708870
 
Diagramadeclassesal
DiagramadeclassesalDiagramadeclassesal
Diagramadeclassesal
Marco Aurélio Galvão
 
introdução ao enterprise architect
introdução ao enterprise architectintrodução ao enterprise architect
introdução ao enterprise architect
Ranieri de Souza
 
Introdução à análise orientada a objetos parte 1
Introdução à análise orientada a objetos parte 1Introdução à análise orientada a objetos parte 1
Introdução à análise orientada a objetos parte 1
ariovaldodias
 
Banco de Dados
Banco de DadosBanco de Dados
Banco de Dados
Fabio Abel
 
Aula sobre Diagrama Classe para a modelagem de requisitos.pptx
Aula sobre Diagrama Classe para a modelagem de requisitos.pptxAula sobre Diagrama Classe para a modelagem de requisitos.pptx
Aula sobre Diagrama Classe para a modelagem de requisitos.pptx
Carlos Albuquerque
 
Slide_Python.pdf
Slide_Python.pdfSlide_Python.pdf
Slide_Python.pdf
HevertonSCosta
 
aula03_uml_diagrama_classe.pdf
aula03_uml_diagrama_classe.pdfaula03_uml_diagrama_classe.pdf
aula03_uml_diagrama_classe.pdf
Antonio Lobato
 
Apostila de uml
Apostila de umlApostila de uml
Apostila de uml
audiclerio
 
Java - Visão geral e Exercícios
Java - Visão geral e ExercíciosJava - Visão geral e Exercícios
Java - Visão geral e Exercícios
Arthur Emanuel
 
Aulas de análise
Aulas de análiseAulas de análise
Aulas de análise
Frank Lira
 
Aulas de análise
Aulas de análiseAulas de análise
Aulas de análise
Frank Lira
 
Modelo de Entidades e Relacionamentos
Modelo de Entidades e RelacionamentosModelo de Entidades e Relacionamentos
Modelo de Entidades e Relacionamentos
Robson Silva Espig
 
Java 10 Classes Abstratas Interfaces
Java 10 Classes Abstratas InterfacesJava 10 Classes Abstratas Interfaces
Java 10 Classes Abstratas Interfaces
Regis Magalhães
 
Diagramas uml
Diagramas umlDiagramas uml
Diagramas uml
Gabriel Faustino
 
Paradigma orientado a objetos - Caso de Estudo C++
Paradigma orientado a objetos - Caso de Estudo C++Paradigma orientado a objetos - Caso de Estudo C++
Paradigma orientado a objetos - Caso de Estudo C++
Sérgio Souza Costa
 

Semelhante a Introdução à análise orientada a objetos parte 3 (20)

Aula 5 uml1 (1)
Aula 5   uml1 (1)Aula 5   uml1 (1)
Aula 5 uml1 (1)
 
Trabalho de análise e projeto 2
Trabalho de análise e projeto 2Trabalho de análise e projeto 2
Trabalho de análise e projeto 2
 
Integração de Tecnologias
Integração de TecnologiasIntegração de Tecnologias
Integração de Tecnologias
 
Java7
Java7Java7
Java7
 
Aula-04-UML.pptx
Aula-04-UML.pptxAula-04-UML.pptx
Aula-04-UML.pptx
 
Diagramadeclassesal
DiagramadeclassesalDiagramadeclassesal
Diagramadeclassesal
 
introdução ao enterprise architect
introdução ao enterprise architectintrodução ao enterprise architect
introdução ao enterprise architect
 
Introdução à análise orientada a objetos parte 1
Introdução à análise orientada a objetos parte 1Introdução à análise orientada a objetos parte 1
Introdução à análise orientada a objetos parte 1
 
Banco de Dados
Banco de DadosBanco de Dados
Banco de Dados
 
Aula sobre Diagrama Classe para a modelagem de requisitos.pptx
Aula sobre Diagrama Classe para a modelagem de requisitos.pptxAula sobre Diagrama Classe para a modelagem de requisitos.pptx
Aula sobre Diagrama Classe para a modelagem de requisitos.pptx
 
Slide_Python.pdf
Slide_Python.pdfSlide_Python.pdf
Slide_Python.pdf
 
aula03_uml_diagrama_classe.pdf
aula03_uml_diagrama_classe.pdfaula03_uml_diagrama_classe.pdf
aula03_uml_diagrama_classe.pdf
 
Apostila de uml
Apostila de umlApostila de uml
Apostila de uml
 
Java - Visão geral e Exercícios
Java - Visão geral e ExercíciosJava - Visão geral e Exercícios
Java - Visão geral e Exercícios
 
Aulas de análise
Aulas de análiseAulas de análise
Aulas de análise
 
Aulas de análise
Aulas de análiseAulas de análise
Aulas de análise
 
Modelo de Entidades e Relacionamentos
Modelo de Entidades e RelacionamentosModelo de Entidades e Relacionamentos
Modelo de Entidades e Relacionamentos
 
Java 10 Classes Abstratas Interfaces
Java 10 Classes Abstratas InterfacesJava 10 Classes Abstratas Interfaces
Java 10 Classes Abstratas Interfaces
 
Diagramas uml
Diagramas umlDiagramas uml
Diagramas uml
 
Paradigma orientado a objetos - Caso de Estudo C++
Paradigma orientado a objetos - Caso de Estudo C++Paradigma orientado a objetos - Caso de Estudo C++
Paradigma orientado a objetos - Caso de Estudo C++
 

Introdução à análise orientada a objetos parte 3

  • 1. Introdução à Análise Orientada a Objetos Prof. Ariovaldo Dias de Oliveira Parte 3
  • 2. Solução da Atividade 2 Segue... class Produto { protected int código; protected String descrição; protected int setor; protected double preço; Produto (int código, String descrição, int setor, double preço) { this.código = código; this.descrição = descrição; this.setor = setor; this.preço = preço; } Produto (int código, String descrição, double preço) { this.código = código; this.descrição = descrição; this.preço = preço; this.setor = 3; }
  • 3. Segue... int getCódigo( ) { return this.código; } String getDescrição() { return this.descrição; } int getSetor( ) { return this.setor; } double getPreço( ) { return this.preço; } double valorICMS ( ) { return this.preço * 0.15; } }
  • 4. Segue... class Alimento extends Produto { private String codVigilância; Alimento (int código, String descrição, double preço, String codVigilância) { super (código, descrição, 1, preço); this.codVigilância = codVigilância; } String getCodVigilância() { return this.codVigilância; } double valorICMS () { String duasprimeiras = (this.codVigilância.substring(0,2)); if (duasprimeiras.equals (&quot;55&quot;)) { return this.preço * 0.1; } else { return this.preço * 0.2; } } }
  • 5. class Atividade2 { public static void main (String args [ ]) { Produto prod1 = new Produto (123, &quot;Sabonete&quot;, 2, 100); Produto prod2 = new Produto (456, &quot;Calça jeans&quot;, 200.0); Alimento prod3 = new Alimento (789, &quot;Arroz&quot;, 300, &quot;55A54BR&quot;); System.out.println(&quot; &quot;); System.out.println(&quot;produto 1 código = &quot; + prod1.getCódigo()); System.out.println(&quot;produto 1 descrição = &quot; + prod1.getDescrição()); System.out.println(&quot;produto 1 setor = &quot; + prod1.getSetor()); System.out.println(&quot;produto 1 preço = &quot; + prod1.getPreço()); System.out.println(&quot;produto 1 ICMS = &quot; + prod1.valorICMS()); System.out.println(&quot; &quot;); System.out.println(&quot;produto 2 código = &quot; + prod2.getCódigo()); System.out.println(&quot;produto 2 descrição = &quot; + prod2.getDescrição()); System.out.println(&quot;produto 2 setor = &quot; + prod2.getSetor()); System.out.println(&quot;produto 2 preço = &quot; + prod2.getPreço()); System.out.println(&quot;produto 2 ICMS = &quot; + prod2.valorICMS()); System.out.println(&quot; &quot;); System.out.println(&quot;produto 3 código = &quot; + prod3.getCódigo()); System.out.println(&quot;produto 3 descrição = &quot; + prod3.getDescrição()); System.out.println(&quot;produto 3 setor = &quot; + prod3.getSetor()); System.out.println(&quot;produto 3 preço = &quot; + prod3.getPreço()); System.out.println(&quot;produto 3 cod vigilância = &quot; + prod3.getCodVigilância()); System.out.println(&quot;produto 3 ICMS = &quot; + prod3.valorICMS()); } } Segue...
  • 6. OBS. Quanto ao valor de ICMS, alguém poderia pensar que ele deveria ser um atributo do Produto, mas é melhor não ser. Veja o texto abaixo (James Rumbaugh): “ Durante a modelagem, é útil distinguir operações que têm efeitos colaterais das que apenas calculam um valor funcional sem modificar qualquer objeto. O último tipo de operação é denominado consulta. As consultas sem argumentos além do objeto-alvo podem ser encaradas como atributos derivados .Por exemplo, a largura de um quadro pode ser calculada pelas posições de seus lados. Um atributo derivado é como um atributo que seja uma propriedade do próprio objeto e seu cálculo não modifica o estado do objeto. Em muitos casos, um objeto tem um conjunto de atributos cujos valores são inter-relacionados e de onde apenas um número fixo de valores pode ser escolhido de forma independente. Um modelo de objetos normalmente deve fazer distinção entre atributos básicos independentes e atributos derivados dependentes.”
  • 7.
  • 8.
  • 9.
  • 10. Exemplo de Diagrama de Classes Funcionário +bonifica (valor: double ): +demite ( ): +getSalário ( ): double Gerente +nome: String +departamento: String # salário: double +admissão: String +rg: String +ativo: boolean +senha: int +autentica (senha: int): boolean
  • 11. Para relacionar Classes usa-se as seguintes nota ç ões:
  • 12. Em UML, Associações são representadas como linhas conectando as classes participantes do relacionamento, e podem também mostrar a regra e a multiplicidade de cada um dos participantes. A multiplicidade é exibida como um intervalo [min...máx] de valores não negativos. Um asterisco (*) no lado máximo representa infinito. Diagrama de Classes
  • 13. A Herança é um dos conceitos fundamentais da programação orientada por objetos, nos quais uma classe ganha todos os atributos e operações da classe que herda, podendo sobrepor ou modificar algumas delas, assim como adicionar mais atributos ou operações próprias. EM UML, uma associação Generalização entre duas classes coloca-as numa hierarquia representando o conceito de Herança de uma classe derivada sob uma classe base. Em UML, Herança é representada por uma linha conectando duas classes, com uma seta no lado da classe base Diagrama de Classes
  • 14. Diagrama de Classes Dependência se define quando uma classe utiliza outra como parâmetro de uma de suas operações. A dependência entre classes indica que os objetos de uma classe usam serviços dos objetos de outra classe. Em UML, Dependência são representadas por uma linha pontilhada conectando duas classes, com uma seta no lado da classe base
  • 15. Diagrama de Classes Agregações são um tipo especial de associação no qual as duas classes participantes não possuem nível igual, mas fazem um relacionamento todo-parte. Uma Agregação descreve como a classe que possui a regra do todo, é composta (tem) de outras classes, que possuem a regra das partes. Para Agregações , a classe que age como o todo sempre tem uma multiplicidade de um. São representadas por uma associação que mostra um losango vazado no lado do todo.
  • 16. Diagrama de Classes Composições são associações que representam agregações muito fortes . Isto significa que Composições formam relacionamentos todo-parte também, mas o relacionamento é tão forte que as partes não pode existir independentes. Elas existem somente dentro do todo, e se o todo é destruído as partes morrem também. Em UML, Composições são representadas por um losango sólido no lado do todo
  • 17. Diagrama de Classes Quando usar Associação Simples, Agregação e Composição? 1) Associação simples : -estabelece uma relação semântica estrutural entre classes. Ex: uma Pessoa trabalha para uma Companhia, uma Companhia tem vários Escritórios, etc. 2) Agregação : -estabelece uma relação todo-parte entre classes, sendo que a parte pode existir sem o todo. Ex: Carro e Roda. Uma Roda é parte de um Carro, porém pode a Roda existe por si só fora do Carro. Você pode por exemplo remover a roda de um carro para colocar em outro. 3) Composição : -estabelece uma relação todo-parte entre classes, sendo que a parte NÃO existe sem o todo. Ex: Pedido e Itens de Pedido. Se você destruir o Pedido, os Itens são destruídos junto, eles não tem sentido se não houver um Pedido. Em http://www.guj.com.br/java/85835-uml---diagrama-de-classes-composicao-x-agregacao
  • 18. Diagrama de Classes Quando usar Associação Simples, Agregação e Composição? 1 - Se eu &quot;deletar&quot; o A, terei que &quot;deletar&quot; também o B ? Sim = composição Não = pode ser agregação ou nada... goto pergunta 2 Exemplo: pedido e compras... um pedido pode ter várias compras, mas se eu deletar o pedido, preciso deletar as compras (não faz sentido eu ter um objeto compra sem que ele esteja em nenhum pedido... sua única razão de existir é &quot;compor&quot; um pedido). 2 - O objeto B tem alguma utilidade sozinho ? Sim = associação comum Não = agregação Exemplo: carro e rodas... se eu deletar um carro, não preciso deletar suas rodas, pois elas podem servir pra outro carro. Isso me fez vir para a pergunta 2, porém uma roda tem utilidade sozinha ? Geralmente não, ela serve sempre para &quot;agregar&quot; uma funcionalidade a outro objeto, como a funcionalidade de andar ao carro (ou a um outro veículo qualquer), ou até mesmo a funcionalidade para crianças sentarem em um &quot;balanço de árvore&quot;, etc.... O caso de composição é o mais claro, agora o de agregação muitas vezes vai da interpretação do analista, pois alguém poderia contestar que uma roda tem sim uma utilidade sozinha para algum caso bizarro que ele observou, ou que existe no &quot;mundo particular dele&quot;. Em http://www.guj.com.br/java/85835-uml---diagrama-de-classes-composicao-x-agregacao
  • 19.
  • 20. UML Diagramas de Caso de Uso Componentes: Ator – é o papel exercido por um usuário, processo ou outro sistema, que irá interagir com um ou vários casos de uso enviando e recebendo mensagens. Os nomes dos atores refletem o papel que um usuário desempenha no sistema.
  • 21. UML Diagramas de Caso de Uso Componentes: Caso de Uso – representa uma funcionalidade completa do sistema, formado por uma sequência de ações que irá gerar um resultado para um ou mais atores. Cada caso de uso possui uma história descritiva das ações que ele realizará, seus métodos de entrada e saída, e as informações que retornará para o ator. Lembrando que o principal foco do caso de uso é dizer O QUE o sistema faz, e não COMO faz.
  • 22. UML Diagramas de Caso de Uso Relacionamento simples – representado por uma linha sólida conectando o ator ao caso de uso o qual ele interage. A linha indica que o relacionamento é bidirecional, o ator envia e recebe informações do caso de uso; pode também ser unidirecional, o ator só envia ou recebe informações. É o único relacionamento exitente entre atores e cados de uso
  • 23. UML Diagramas de Caso de Uso Relacionamento de inclusão (include) – ocorre quando um caso de uso precisa dos recursos de outro, desejamos reduzir a complexidade de um caso de uso ou evitar repetições. É representado por uma seta tracejada rotulada com a palavra << include >>. A seta aponta para o caso de uso solicitado
  • 24. UML Diagramas de Caso de Uso Relacionamento de extensão (extends) – ocorre quando um caso de uso precisa de recursos de outro, não sendo vitais para a realização do mesmo. Em outras palavras, um caso de uso pode usar os recursos de outro, não sendo obrigatório esse uso. É representado por uma seta tracejada rotulada com a palavra << extends >>. A seta aponta para o caso de uso solicitante.
  • 25. UML Diagramas de Caso de Uso Generalização – indica que temos especializações de um ator ou caso de uso, indicando comportamentos específicos. Ou seja, posso ter atores especializados para um ou mais casos de uso, assim como casos de uso especializados para uma ou mais tarefas no sistema. É representado por uma seta com ponta sem preenchimento que aponta para o ator ou caso de uso base.
  • 26. UML Diagramas de Caso de Uso Exemplo : temos um sistema de controle de estoque. O funcionário renova o estoque dos produtos quando ele recebe mais produtos do fornecedor e o sistema lhe informa do estoque baixo. O gerente cuida da geração dos relatórios que podem ser usados na auditoria da fiscalização. Percebe-se que os casos de uso estão dentro de um retângulo, que representa a fronteira do sistema. Os casos de uso externos ao retângulo não farão parte do desenvolvimento do sistema. Podemos também incluir notas informativas para esclarecer certos papéis e relacionamentos, como é o caso de “Renovar estoque”.
  • 27.
  • 28.
  • 29. Exemplo de Diagrama de Sequência
  • 30.
  • 31.
  • 32. Atividade 4 Suponha que você é o responsável para a implementação de Informática em uma pequena empresa. Seu trabalho começa por entrevistas com os envolvidos, para saber exatamente as necessidades da empresa, e onde e como a Informática pode ajudar. Levando-se em conta as costumeiras restrições orçamentária, você, juntamente com seu gerente, decidem por começar pela parte onde pode-se obter mais rapidamente algum resultado positivo. Sua formação profissional está voltada para Orientação a Objetos e você realmente acredita que o paradigma OO é o melhor que se tem no momento. Após algum tempo de trabalho, você já tem pronto um levantamento (baseado em OO) das classes envolvidas e seus relacionamentos. Também já preparou o Diagrama de Classes , Diagrama de Casos de Uso e Diagrama de Sequência . Hoje é o dia de apresentar este material para o gerente e equipe que trabalhará com você no desenvolvimento do Sistema. Segue...
  • 33.
  • 34.

Notas do Editor

  1. Introdução à Análise Orientada a Objetos Parte 3
  2. Introdução à Análise Orientada a Objetos Parte 3
  3. Introdução à Análise Orientada a Objetos Parte 3
  4. Introdução à Análise Orientada a Objetos Parte 3
  5. Introdução à Análise Orientada a Objetos Parte 3
  6. Introdução à Análise Orientada a Objetos Parte 3
  7. Introdução à Análise Orientada a Objetos Parte 3
  8. Introdução à Análise Orientada a Objetos Parte 3
  9. Introdução à Análise Orientada a Objetos Parte 3
  10. Introdução à Análise Orientada a Objetos Parte 3
  11. Introdução à Análise Orientada a Objetos Parte 3
  12. Introdução à Análise Orientada a Objetos Parte 3
  13. Introdução à Análise Orientada a Objetos Parte 3
  14. Introdução à Análise Orientada a Objetos Parte 3
  15. Introdução à Análise Orientada a Objetos Parte 3
  16. Introdução à Análise Orientada a Objetos Parte 3
  17. Introdução à Análise Orientada a Objetos Parte 3
  18. Introdução à Análise Orientada a Objetos Parte 3
  19. Introdução à Análise Orientada a Objetos Parte 3
  20. Introdução à Análise Orientada a Objetos Parte 3
  21. Introdução à Análise Orientada a Objetos Parte 3
  22. Introdução à Análise Orientada a Objetos Parte 3
  23. Introdução à Análise Orientada a Objetos Parte 3
  24. Introdução à Análise Orientada a Objetos Parte 3
  25. Introdução à Análise Orientada a Objetos Parte 3
  26. Introdução à Análise Orientada a Objetos Parte 3
  27. Introdução à Análise Orientada a Objetos Parte 3
  28. Introdução à Análise Orientada a Objetos Parte 3
  29. Introdução à Análise Orientada a Objetos Parte 3
  30. Introdução à Análise Orientada a Objetos Parte 3
  31. Introdução à Análise Orientada a Objetos Parte 3
  32. Introdução à Análise Orientada a Objetos Parte 3
  33. Introdução à Análise Orientada a Objetos Parte 3
  34. Introdução à Análise Orientada a Objetos Parte 3