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

7.
UML <ul><li>A Unified Modelling Language (UML) é uma linguagem ou notação de diagramas para especificar, visualizar e documentar modelos de 'software' orientados por objetos. O UML não é um método de desenvolvimento, o que significa que não lhe diz o que fazer primeiro ou o que fazer depois ou como desenhar o seu sistema, mas ajuda-o a visualizar o seu desenho e a comunicar com os outros. A UML é controlado pelo Object Management Group (OMG) e é a norma da indústria para descrever graficamente o 'software'. </li></ul>

8.
UML <ul><li>A UML é composta por muitos elementos de modelo (diagramas) que representam as diferentes partes de um sistema de software. Os elementos UML são usados para criar diagramas, que representam um determinada parte, ou um ponto de vista do sistema. Os principais diagramas são </li></ul><ul><ul><li>Diagrama de Classes </li></ul></ul><ul><ul><ul><li>mostra classes e os relacionamentos entre elas </li></ul></ul></ul><ul><ul><li>Diagrama de Caso de Uso </li></ul></ul><ul><ul><ul><li>mostra atores (pessoas ou outros usuários do sistema), casos de uso (os cenários onde eles usam o sistema), e seus relacionamentos </li></ul></ul></ul><ul><ul><li>Diagrama de Sequência </li></ul></ul><ul><ul><ul><li>mostra objetos e uma sequência das chamadas do método feitas para outros objetos. </li></ul></ul></ul>

9.
UML Diagrama de Classes <ul><ul><li>Mostram as diferentes classes que fazem um sistema e como elas se relacionam. Os Diagramas de Classe são chamados diagramas estáticos porque mostram as classes, com seus métodos e atributos bem como os relacionamentos estáticos entre elas: quais classes conhecem quais classes ou quais classes são parte de outras classes, mas não mostram a troca de mensagens entre elas. </li></ul></ul>

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.
UML Diagramas de Caso de Uso <ul><li>Descrevem relacionamentos e dependências entre um grupo de Caso de Uso e os Atores participantes no processo. </li></ul><ul><li>É importante observar que Diagramas de Caso de Uso não são adequados para representar o desenho, e não podem descrever os mecanismos internos de um sistema. Diagramas de Caso de Uso são feitos para facilitar a comunicação com os futuros usuários do sistema, e com o cliente, e são especialmente úteis para determinar os recursos necessários que o sistema deve ter. Diagramas de Caso de Uso dizem o quê o sistema deve fazer, mas não fazem — e não podem — especificar como isto será conseguido. </li></ul>

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.
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 <ul><li>O funcionário acessa a área de renovação de estoque do sistema </li></ul><ul><li>O sistema informa os produtos que estão em baixa. </li></ul><ul><li>Funcionário seleciona o produto que será renovado. </li></ul><ul><li>Sistema mostra uma tela para pesquisar o número da nota fiscal de compra. </li></ul><ul><li>Funcionário preenche o campo e manda procurar. </li></ul><ul><li>Sistema exibe a nota fiscal encontrada. </li></ul><ul><li>Funcionário seleciona a nota fiscal. </li></ul><ul><li>Funcionário confirma os dados e manda o sistema renovar estoque </li></ul><ul><li>Sistema informa que o estoque para aquele produto foi renovado e libera para venda. </li></ul>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.

28.
UML Diagramas de Sequência <ul><ul><li>Mostram a troca de mensagens (isto é chamada de método) entre diversos Objetos, numa situação específica e delimitada no tempo. Diagramas de Sequência colocam ênfase especial na ordem e nos momentos nos quais mensagens para os objetos são enviadas. </li></ul></ul>

29.
Exemplo de Diagrama de Sequência

30.
UML Outros Diagramas <ul><li>Além dos exemplificados, existem outros diagramas UML: </li></ul><ul><li>Diagrama de Objetos </li></ul><ul><li>Diagramas de Interação </li></ul><ul><li>Diagramas de Colaboração </li></ul><ul><li>Diagramas de Gráficos de Estados </li></ul><ul><li>Diagramas de Atividades </li></ul><ul><li>Diagramas de Componentes </li></ul><ul><li>Diagramas de Implantação </li></ul>

31.
Tecnologias de Implementação <ul><li>Ferramentas CASE: </li></ul><ul><ul><li>Rational Rose (Rational), Visio Enterprise (Microsoft) etc. </li></ul></ul><ul><li>Linguagens Orientadas a Objetos: </li></ul><ul><ul><li>Java, J++, J#, C#, VB.NET, C++ e Smalltalk </li></ul></ul><ul><li>Ambientes de Desenvolvimento: </li></ul><ul><ul><li>VisualAge for Java (WebSphere) (IBM) </li></ul></ul><ul><ul><li>Oracle Applications (Oracle) </li></ul></ul><ul><ul><li>Visual Studio .NET (Microsoft) </li></ul></ul><ul><ul><li>Visual Café (Symantec) </li></ul></ul><ul><ul><li>Jbuilder (Borland/Inprise) </li></ul></ul><ul><li>Banco de Dados Orientado a Objetos: </li></ul><ul><ul><li>O2 (O2 Technology) </li></ul></ul><ul><ul><li>Objectstore (Object Design Inc.) </li></ul></ul><ul><ul><li>Jasmine (Computer Associates) </li></ul></ul>

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.
Atividade 4 <ul><li>Apresente (em PowerPoint) o material que você preparou. (No máximo 2 Casos de Uso e 2 Diagramas de Sequência) </li></ul><ul><li>OBS: Sua empresa é uma das abaixo (sorteada entre os grupos da classe): </li></ul><ul><li> </li></ul><ul><ul><ul><ul><li>1 - Uma farmácia </li></ul></ul></ul></ul><ul><ul><ul><ul><li>2 - Uma oficina de funilaria </li></ul></ul></ul></ul><ul><ul><ul><ul><li>3 - Um consultório dentário </li></ul></ul></ul></ul><ul><ul><ul><ul><li>4 - Um laboratório de análises clínicas </li></ul></ul></ul></ul><ul><ul><ul><ul><li>5 - Um cursinho preparatório para Vestibular </li></ul></ul></ul></ul><ul><ul><ul><ul><li>6 - Uma locadora de DVD’s </li></ul></ul></ul></ul><ul><ul><ul><ul><li>7 - Uma agência de emprego </li></ul></ul></ul></ul><ul><ul><ul><ul><li>8 - Uma academia de ginástica </li></ul></ul></ul></ul>

34.
Referências <ul><li>Java e Orientação a Objetos. Disponível em <http://www.ufpa.br/cdesouza/teaching/cedai/4-uml-introduction.pdf> Acesso em 23 mar 2011. </li></ul><ul><li>Fundamentos do UML. Disponível em <http://docs.kde.org/stable/pt_BR/kdesdk/umbrello/ uml-elements. html#use-case-diagram> Acesso em 23 mar 2011. </li></ul><ul><li>UML Resource Page. Disponível em </li></ul><ul><li>http://www.uml.org/> Acesso em 28 jan 2011 </li></ul><ul><li><http:// www.guj.com.br/java/85835-uml---diagrama-de-classes-composicao-x-agregacao> Acesso em 21 fev 2011 </li></ul><ul><li><http://hslife.com.br/2010/10/03/resumo-de-uml-casos-de-uso/> </li></ul><ul><li>Acesso em 21 fev 2011 </li></ul>