O documento apresenta conceitos de análise orientada a objetos e modelagem UML. Descreve classes Produto e Alimento com atributos e métodos. Explica diagramas de classes UML, mostrando herança, agregação e composição. Também explica diagramas de casos de uso UML e seus componentes.

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 ("55")) { 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, "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...

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

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 "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

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

29. Exemplo de Diagrama de Sequência

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