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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Visibilidade no Rose público privado protegido CIn-UFPE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Exemplo de relacionamento com atributo CIn-UFPE

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

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

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

Exemplo de diagrama de classe: Escola CIn-UFPE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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