Análise e Projeto de Sistemas

Apresentação em tema: "Análise e Projeto de Sistemas"— Transcrição da apresentação:

1 Análise e Projeto de Sistemas
Introdução ao Projeto Orientado a Objeto com UML CIn-UFPE

2 Revisar os princípios do paradigma de orientação a objetos
Objetivos Revisar os princípios do paradigma de orientação a objetos Apresentar os conceitos de orientação a objetos com a notação UML correspondente Foco em aspectos estruturais: diagramas de classes CIn-UFPE

3 Características do projeto OO
A funcionalidade do sistema é expressa em termos de serviços de objetos (agrupados em classes) Áreas de dados compartilhadas são eliminadas. Objetos se comunicam através de passagem de mensagens Pela própria natureza, objetos podem ser distribuídos Potencialmente, embutem características como abstração, encapsulamento, information hiding, modularidade e extensibilidade CIn-UFPE

4 Desenvolvimento orientado a objeto
Análise, projeto e programação orientados a objeto são relacionados, mas são distintos Análise orientada a objeto trata do desenvolvimento de um modelo orientado a objeto do domínio da aplicação (independente da implementação) Projeto orientado a objeto trata do desenvolvimento de um modelo orientado a objeto voltado para a implementação dos requisitos Programação orientada a objeto trata da realização de um projeto orientado a objeto usando uma linguagem de programação OO, como Java ou C++ CIn-UFPE

5 Modelo de um objeto real Possui comportamento, estado e identidade
entidade física, conceitual ou de software Possui comportamento, estado e identidade Exemplo: conta, funcionario, livro, ponto de venda, ... donut Um objeto representa uma entidade física, conceitual ou de software. Um objeto é uma manifestação concreta de uma abstração; uma entidade que encapsula estado e comportamento; uma instância de uma classe. O estado de um objeto é uma das possíveis condições que o objeto pode existir e normalmente muda com o passar do tempo; é um conjunto de propriedades que o objeto possui. Comportamento determina como um objeto age e reage a pedidos (para realização de operações) de outros métodos. É representado pelo conjunto de mensagens que o objeto é capaz de responder. Cada objeto possui também um identidade única no sistema, tornando assim possível que dois objetos mesmo com estados iguais possam ser identificados como diferentes. Um objeto é qualquer pessoa, lugar, evento, coisa, tela, relatório, ou conceito aplicável ao sistema. Um objeto pode ser qualquer coisa que faça parte do seu sistema. Os donuts são uma representação gráfica usada pela IBM para objetos. CIn-UFPE

6 Objetos em UML : Conta contaSaque contaSaque : Conta
Apenas o nome da classe Nome da classe e do objeto Apenas o nome do objeto Os exemplos acima mostram as diferentes formas em que um objeto pode ser modelado em UML. CIn-UFPE

7 Classe Descrições de objetos com propriedades e comportamento comuns
Abstração que enfatiza o que é relevante suprime o que não interessa Classes são fábricas de objetos Objetos são agrupados em classes Uma classe é uma descrição de um conjunto de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica (esses conceitos serão vistos mais adiante). A identificação das características relevantes (uso do princípio de abstração) e comuns a um conjunto de objetos e definição de classes ajuda a tratar a complexidade de sistemas. CIn-UFPE

8 Quantas classes temos aqui?
Classes de Objetos Quantas classes temos aqui? Fonte: Rational CIn-UFPE

9 Classe em UML Conta estrutura comportamento Nome da Classe numero
Atributos Operações numero saldo credito() debito() getSaldo() getNumero() estrutura comportamento O exemplo acima mostra como modelar uma classe em UML, identificando o seu nome, atributos e operações. A representação dos atributos e operações é opcional. CIn-UFPE

10 Classes: mais exemplos
Indivíduo código : long sexo : char nome : String incluir() atualizar() CIn-UFPE

11 Classes: atributos Um atributo representa alguma propriedade que é compartilhada por todos os objetos da classe Os atributos descrevem os dados contidos nas instâncias de uma classe Em um dado momento, um objeto de uma classe conterá valores para todos os atributos descritos na sua classe CIn-UFPE

12 Atributos: notação Conta
Atributos podem ser identificados apenas com nomes Conta numero: integer Saldo: real Atributos podem ter seus tipos (ou classes) especificados e terem valores padrão definidos Parede altura : real largura : real espessura : real viga : boolean = false CIn-UFPE

13 Objetos com atributos valorados
: Conta numero = saldo = 875,32 Valor do Atributo Conta numero saldo : Conta numero = saldo = 500,00 O exemplo acima ilustra objetos com diferentes valores de atributos. CIn-UFPE

14 Classes: operações Uma operação é uma abstração de algum serviço que se pode requisitar a um objeto e que é compartilhado por todos os objetos da classe Um classe pode ter qualquer número de operações, inclusive nenhuma CIn-UFPE

15 Operações: notação Como para os atributos, pode-se especificar uma operação apenas com seu nome Conta Especificação das operações credito() debito() getSaldo() getNumero() Pode-se também especificar a assinatura da operação: seus parâmetros, o tipo desses parâmetros e o tipo de retorno CIn-UFPE

16 Classes: visibilidade
Marcações de acesso podem ser usadas para especificar o tipo de acesso permitido aos atributos e operações + público: todos os objetos do sistema podem usar # protegido: qualquer descendente da classe pode usar privado: somente a própria classe pode usar CIn-UFPE

17 Visibilidade no Rose público privado protegido CIn-UFPE

18 Comunicação entre objetos
Conceitualmente, objetos se comunicam através da troca de mensagens. Componentes de uma mensagem Nome do serviço requisitado pelo objeto que está fazendo a chamada. Informação requerida para executar o serviço e o nome de um proprietário para o resultado do serviço. Na prática, mensagens são normalmente implementadas através de chamadas de procedimentos (operações) Nome = nome do procedimento. Informação = lista de parâmetros para o procedimento. CIn-UFPE

19 Exemplos de mensagem // Chama um método associado a um objeto buffer que // retorna o próximo valor no buffer v = circularBuffer.Get () ; // Chama o método associado ao objeto termostato // que define a temperatura a ser mantida thermostat.setTemp (20) ; CIn-UFPE

20 Componente Parte não trivial, quase independente, substituível de um sistema, que provê a realização de (uma/um conjunto de) interface(s) Exemplos um código fonte um componente executáve tabelas de bancos de dados Um componente é uma parte do sistema que provê a realização física de um conjunto de interfaces. Desenvolvimento baseado em componentes é a criação e implantação de software composto por componentes. CIn-UFPE

21 Componentes em UML <<EXE>> Arquivo executável
Arquivo fonte <<EXE>> Arquivo executável Acima alguns exemplos de componentes são ilustrados em UML. CIn-UFPE

22 Pacote Mecanismo para organizar elementos em grupos
Facilita entendimento do sistema Favorece modularidade e reuso em larga escala Essencial para estruturar sistemas complexos nome do pacote Um pacote representa um grupo de classes relacionadas, e possivelmente outros pacotes, de acordo com algum ponto de vista ou critério. O uso de pacotes para encapsular classes relacionadas favorece modularidade e consequentemente reuso em larga escala e manutenção, sendo assim essencial para estruturar sistemas orientados a objetos complexos. Quando o número de classes do seu sistema é muito alto, você deve organizá-las em pacotes para facilitar o seu entendimento CIn-UFPE

23 Subsistema União de pacote (agrupa outros elementos)
classe (comportamento) Subsistema é um elemento que possui a semântica de um pacote, pois contém outros elementos, e uma classe, porque possui comportamento. O comportamento de um subsistema é provido pelas classes e subsistemas que ele contém. Um subsistema realiza uma ou mais interfaces, que definem o seu comportamento. CIn-UFPE

24 Subsistema em UML <<subsystem>> Nome do subsistema
Subsistemas são representados em UML com um elemento de pacote com o estereótipo <<subsystem>>. CIn-UFPE

25 Relacionamentos Objetos e classes de objetos participam de relacionamentos com outros objetos e classes de objetos Tipos de relacionamento Associação simples agregação composição Dependência Generalização Realização CIn-UFPE

26 Navegabilidade de um relacionamento
Em geral a navegação entre as classes de um relacionamento é bi-direcional Porém é possível limitá-la a apenas uma direção CIn-UFPE

27 Multiplicidade de um relacionamento
Define quantos objetos participam do relacionamento O número de instâncias de uma classe relacionada a uma instância de outra classe Especificado em cada uma das pontas do relacionamento Multiplicidade indica, numa associação, quantos objetos de uma classe podem estar associados com uma instância da outra classe participante da associação. CIn-UFPE

28 Tipos de multiplicidade
Não especificada Exatamente um Zero ou mais Muitos (mesmo que 0..*) Um ou mais Zero ou um Intervalo determinado Valores múltiplos 1 0..* * 1..* 0..1 2..4 2, 4..6 CIn-UFPE

29 Associação simples Relação estrutural entre classes Companhia
Empregado 1..* * contrata 1 0..* CIn-UFPE

30 Associação unária Quando há um relacionamento de uma classe consigo própria CIn-UFPE

31 Relacionamentos e papéis
Nome de papéis são úteis para distinguir relacionamentos entre o mesmo par de classes CIn-UFPE

32 Relacionamentos com atributos
Modela as propriedades associadas com um relacionamento Para indicar os atributos de um relacionamento, usamos uma linha tracejada para unir o relacionamento às suas propriedades As propriedades devem ser representadas por uma classe CIn-UFPE

33 Exemplo de relacionamento com atributo
CIn-UFPE

34 Agregação Uma forma especial de associação entre o todo e suas partes, no qual o todo é composto das partes Departamento Empresa Todo Parte Agregação CIn-UFPE

35 Composição Uma forma mais forte de agregação
Há uma coincidência da vida das partes Uma vez criada a parte ela irá viver e morrer com o todo O “Todo” é responsável pelo gerenciamento da criação e destruição das partes CIn-UFPE

36 Exemplo de Composição CIn-UFPE Pedido -codigo: Integer
+confirmar() +cancelar() -calcularTotal():Currency gerarNovoCodigo: String -codigo: Integer -dataRecebido -total: Currency Pedido -quantidade: Integer -preco: Currency Item de Pedido Produto * CIn-UFPE

37 Exemplo de diagrama de classe: Escola
CIn-UFPE

38 Associação x Agregação x Composição
Composição ou agregação? Na dúvida, use agregação! Agregação ou associação? Na dúvida, use associação! CIn-UFPE

39 Dependência Dependências são relações de uso
mais fraco que associação Uma dependência indica que mudanças em um elemento (o “servidor”) podem afetar outro elemento (o “cliente”) Uma dependência entre classes indica que os objetos de uma classe usam serviços dos objetos de outra classe CIn-UFPE

40 Dependência Pode existir relacionamento de dependência entre vários elementos de UML Classe Cliente Fornecedor Componente Cliente Fornecedor Pacote PacoteCliente PacoteFornecedor Dependência Fonte: Rational CIn-UFPE

41 Generalização (ou herança)
Uma generalização (também conhecida como herança) é um relacionamento entre um elemento mais geral (chamado de superclasse ou pai) e um mais específico (chamado de subclasse ou filho) Classes são organizadas numa hierarquia onde uma super classe é uma generalização de uma ou mais sub classes Uma sub classe herda os atributos e operações de sua super classe e pode adicionar seus próprios métodos ou atributos CIn-UFPE

42 Herança simples Classes herdando de apenas uma outra classe Figura
Círculo raio centro desenhar() Retângulo vertices diagonal() Figura cor largura da linha girar(graus) selecionar() Subclasses Superclasse (pai) Quadrado Relacionamento de Generalização CIn-UFPE

43 Herança múltipla Classes herdando de mais de uma classe Herança
Mamífero AnimalVoador Herança múltipla Cachorro Morcego Passarinho Gaviao Gato CIn-UFPE

44 Vantagens da herança É um mecanismo de abstração que pode ser usado para classificar entidades É um mecanismo de reuso tanto em nível de projeto como em nível de programação CIn-UFPE

45 Problemas com a herança
Classes de objeto não são auto-contidas. Elas não podem ser entendidas sem a referência a suas super classes Herança introduz complexidade e isso é indesejável, especialmente em sistemas críticos Herança múltipla: conflito de nomes CIn-UFPE

46 Realização e Interfaces
Realização é uma relação pela qual um elemento especifica o contrato que outro elemento deve implementar A realização é um relacionamento entre uma especificação de interface e sua implementação CIn-UFPE

47 Interface Interfaces definem um tipo especificando apenas a assinatura de seus métodos Interfaces não possuem atributos e seus métodos não têm corpo Diferentemente das classes, as interfaces não especificam nenhuma estrutura Classes implementam interfaces provêem implementação para os métodos especificados em uma interface Uma interface define um tipo especificando apenas a assinatura (parâmetros de entrada e saída) dos métodos pertencentes a este tipo. São definidos então o nome, tipos de argumento e resultado dos métodos de uma classe mas não o código para a implementação destes métodos. Classes implementam interfaces, isto é, classes provêem implementação para os métodos especificados em uma interface. Ao implementar uma interface, uma classe deve prover implementação para todos os métodos definidos na interface, a não ser que esta classe seja abstrata. Quando uma classe implementa uma interface, provendo implementação para todos os métodos da interface, dizemos que esta classe é do tipo da interface. Pense assim: quando uma classe é do tipo de uma interface, esta classe pode ser usada em qualquer lugar que estiver sendo esperado um objeto do tipo desta interface. Dois elementos são polimórficos se eles implementam a mesma interface. CIn-UFPE

48 Realização: notação Realização Subsistema Classe Componente CIn-UFPE

49 Realização: outro exemplo
Porca8mm Porca6mm Porca4mm Apertar Afrouxar <<interface>> ChaveKit Relacionamentos de realização Uma interface é uma coleção de operações, usadas para especificar um serviço de uma classe ou componente. CIn-UFPE

50 Realização: outro exemplo
Porca8mm Porca6mm ChaveKit Porca4mm Uma interface é uma coleção de operações, usadas para especificar um serviço de uma classe ou componente. Relacionamentos de realização CIn-UFPE

51 Subsistemas x Componentes
Ambos encapsulam um comportamento modelado por interfaces Subsistemas representam componentes no modelo de projeto Componentes são a realização física dos subsistemas Projeto <<subsystem>> Nome do subsistema Implementação Subsistemas e componentes: ambos encapsulam um conjunto de comportamentos modelado por interfaces. Um componente provê a realização física de um conjunto de interfaces. Componentes são elementos de implementação. Um componente é um subsistema implementado. Nome do componente CIn-UFPE

52 Classe abstrata é aquela que não possui instância
Em geral, possui pelo menos um método abstrato Métodos abstratos não têm corpo subclasses não abstratas são obrigadas a fornecer uma implementação para eles Uma classe abstrata é aquela que não possui instâncias. Em geral, possui pelo menos um método abstrato, isto é, método com interface definida mas sem implementação, a ser implementado nas subclasses da classe abstrata. Toda classe que herdar de uma classe abstrata e não for abstrata deve prover implementação para todos os métodos abstratos definidos na sua superclasse. CIn-UFPE

53 Classes, Interfaces e Classes Abstratas
Atributos Métodos Classes Abstratas Assinatura de Métodos Interfaces Assinaturas dos métodos Classes - possibilita herança de todo o código Classes abstratas - herança de parte do código Interfaces - implementação parte do zero; herança só de comportamento CIn-UFPE

54 Classes abstratas x Interfaces
Herança de tipos x herança de código Classes descrevem propriedades fundamentais de um objeto Interfaces descrevem papéis desempenhados por um objeto em determinadas situações Interfaces são úteis para implementar herança múltipla É importante saber quando devemos usar herança de classe e implementação de interface: classes descrevem propriedades fundamentais de um objeto, enquanto que interfaces descrevem papéis desempenhados por um objeto em determinadas situações. CIn-UFPE

55 Mecanismos adicionais de UML
Estereótipos Notas Propriedades (Tagged values) Restrições Por fim, veremos alguns dos mecanismos adicionais de UML: estereótipos, notas, rótulos e restrições. CIn-UFPE

56 Estereótipos Mecanismo utilizado para estender os elementos de UML
Define um novo modelo de elemento em termos de outro já existente Como criando um novo ícone utilizando a notação <<novo_elemento>> CIn-UFPE

57 Estereótipos: exemplo
Classes de fronteira: <<boundary>> ClasseFronteira ClasseFronteira Veremos este e outros estereótipos padrão de UML no decorrer do curso. CIn-UFPE

58 Notas Anotação utilizada para adicionar informação a diagramas
Pode ser afixada a qualquer elemento de UML Pode ser ligada a um elemento com uma linha tracejada Exemplo: Esta classe é uma abstração do dispositivo de hardware que será usado para ler efetivamente as informações do cartão magnético. LeitoraCartao CIn-UFPE

59 Propriedades (Tagged Values)
Servem para estender elementos UML, adicionando informações sobre eles Exemplos já definidos em UML: Persistence (valores: persistent, transient) Location (ex. de valores: client, server) Você pode criar suas próprias propriedades Cliente {persistence=persistent} : LeitoraCartao {location=server} CIn-UFPE

60 Restrições Usadas para criação de novas regras sobre elementos do modelo Ou modificação de regras existentes Pessoa Funcionário Empresa 1 1..* {subset} Diretor 3 1 CIn-UFPE