©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/58 Análise e Projeto de Sistemas...

View
214
Download
1
Category

Documents

Preview:

Citation preview

Análise e Projeto de SistemasAnálise e Projeto de Sistemas

Introdução ao Projeto Orientado a Objeto com UML

ObjetivosObjetivos

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

Características do projeto OOCaracterí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

Desenvolvimento orientado a objetoDesenvolvimento 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++

ObjetoObjeto

Modelo de um objeto real entidade física, conceitual ou de software

Possui comportamento, estado e identidade

Exemplo: conta, funcionario, livro, ponto de venda, ...

donut

Objetos em UMLObjetos em UML

Apenas o nome do objeto

: Conta

contaSaque :Conta

contaSaqueApenas o nome da classe

Nome da classe e do objeto

ClasseClasse

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

Classes de ObjetosClasses de Objetos

Quantas classes temos aqui?

Fonte: Rational

Classe em UMLClasse em UML

Conta

Nome da Classe Conta

Atributos Operações

numerosaldocredito()debito()getSaldo()getNumero()

estrutura

comportamento

Classes: mais exemplosClasses: mais exemplos

Indivíduo

Indivíduocódigo : longsexo : charnome : String

Indivíduo

código : longsexo : charnome : String

incluir()atualizar()

Indivíduo

incluir()atualizar()

Classes: atributosClasses: 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

Atributos: notaçãoAtributos: notação Atributos podem ser identificados apenas com nomes

Atributos podem ter seus tipos (ou classes) especificados e terem valores padrão definidos

Paredealtura : reallargura : realespessura : realviga : boolean = false

Conta

numero: integerSaldo: real

Objetos com atributos valoradosObjetos com atributos valorados

: Conta

numero = 23.025-1saldo = 500,00

: Conta

numero = 21.342-7saldo = 875,32

Conta

numerosaldo

Valor do Atributo

Objeto

Classes: operaçõesClasses: 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

Operações: notaçãoOperações: notação

Como para os atributos, pode-se especificar uma operação apenas com seu nome

Pode-se também especificar a assinatura da operação: seus parâmetros, o tipo desses parâmetros e o tipo de retorno

Conta

credito()debito()getSaldo()getNumero()

Especificação das operações

Classes: visibilidadeClasses: 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

Visibilidade no RoseVisibilidade no Rose

Pessoanome : Stringcpf : Stringtelefone : String

incluir()consultar()atualizar()

público

privado

protegido

Comunicação entre objetosComunicaçã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.

Exemplos de mensagemExemplos 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) ;

ComponenteComponente

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

Componentes em UMLComponentes em UML

Arquivo fonte<<EXE>>Arquivo

executável

PacotePacote

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

SubsistemaSubsistema

União de pacote (agrupa outros elementos) classe (comportamento)

Subsistema em UMLSubsistema em UML

<<subsystem>>

Nome do subsistema

RelacionamentosRelacionamentos

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

Navegabilidade de um relacionamentoNavegabilidade 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

Usuário Senha

Multiplicidade de um relacionamentoMultiplicidade 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

Tipos de multiplicidadeTipos 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

0..*

1..*

0..1

2..4

2, 4..6

Associação simplesAssociação simples

Relação estrutural entre classes

Companhia Empregado1..** 1..** contrata

10..*0..*

Associação unáriaAssociação unária

Quando há um relacionamento de uma classe consigo própria

Funcionário

1..*

gerencia

Nome de papéis são úteis para distinguir relacionamentos entre o mesmo par de classes

Relacionamentos e papéisRelacionamentos e papéis

Companhia Empregado1..** 1..**

+empregador

contrata

10..*

+subordinado

+chefe0..*

Relacionamentos com atributosRelacionamentos 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

Exemplo de relacionamento com atributoExemplo de relacionamento com atributo

Companhia Empregado1..*** 1..*

+empregador

Trabalhodescriçãosalário

AgregaçãoAgregação

Uma forma especial de associação entre o todo e suas partes, no qual o todo é composto das partes

DepartamentoEmpresa

Todo Parte

Agregação

ComposiçãoComposiçã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

Exemplo de ComposiçãoExemplo de Composição

+confirmar()+cancelar()-calcularTotal():CurrencygerarNovoCodigo: String

-codigo: Integer-dataRecebido-total: Currency

Pedido

-quantidade: Integer-preco: Currency

Item de Pedido

Produto

Exemplo de diagrama de classe: EscolaExemplo de diagrama de classe: Escola

Associação Associação x x Agregação Agregação xx Composição Composição

Composição ou agregação? Na dúvida, use agregação!

Agregação ou associação? Na dúvida, use associação!

DependênciaDependê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

Cliente Servidor

DependênciaDependência

Pode existir relacionamento de dependência entre vários elementos de UML

Classe

Pacote

PacoteFornecedor

ComponenteFornecedorCliente

PacoteClienteDependência

Fonte: Rational

FornecedorCliente

Generalização (ou herança)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

Herança simplesHerança simples

Classes herdando de apenas uma outra classe

Relacionamentode Generalização

Círculoraiocentrodesenhar()

Retânguloverticesdesenhar()diagonal()

Figuracorlargura da linhadesenhar()girar(graus)selecionar()

Subclasses

Superclasse(pai)

Quadrado

Herança múltiplaHerança múltipla

Classes herdando de mais de uma classe

Mamífero AnimalVoadorHerançamúltipla

Cachorro Gato Morcego Passarinho Gaviao

Vantagens da herançaVantagens 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

Problemas com a herançaProblemas 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

Realização e InterfacesRealizaçã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

InterfaceInterface

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

Realização: notaçãoRealização: notação

Empregado

verificarFicha()calcularSalário()

<<interface>>

Empregado_Impl

Realização

SubsistemaClasse Componente

Realização

Realização: outro exemploRealização: outro exemplo

Porca8mm

Porca6mm

Porca4mm

ApertarAfrouxar

<<interface>>ChaveKit

Relacionamentos de realização

Realização: outro exemploRealização: outro exemplo

ChaveKit

Relacionamentos de realização

Porca8mm

Porca6mm

Porca4mm

Subsistemas x ComponentesSubsistemas 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

Implementação

Nome do componente

<<subsystem>>Nome do subsistema

Classe abstrataClasse abstrata

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

Classes, Interfaces Classes, Interfaces e e Classes AbstratasClasses Abstratas

Classes

• Atributos• Métodos

Classes Abstratas

• Atributos• Métodos• Assinatura de Métodos

Interfaces

• Assinaturas dos métodos

Classes abstratas x InterfacesClasses 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

Mecanismos adicionais de UMLMecanismos adicionais de UML

Estereótipos Notas Propriedades (Tagged values) Restrições

EstereótiposEstereó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>>

Estereótipos: exemploEstereótipos: exemplo

Classes de fronteira:

ClasseFronteira

<<boundary>>ClasseFronteira

NotasNotas

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:

LeitoraCartao

Esta classe é uma abstração do dispositivo de hardware que será usado para ler efetivamente as informações do cartão magnético.

Propriedades (Propriedades (Tagged ValuesTagged 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}

RestriçõesRestrições

Pessoa Empresa{subset}

Funcionário

Diretor1..* 1

3 1

Usadas para criação de novas regras sobre elementos do modelo

Ou modificação de regras existentes

Recommended

©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/45 Análise e Projeto de Sistemas if718 Augusto Sampaio 2008.2 Em co-autoria com

Documents

CIn-UFPE1 Recuperação de Informação Preparação do documentos Flávia Barros

Documents

Cin - Interiores

Documents

CIn-UFPE1 Recuperação de Informação Eduardo Amaral - efas Frederico Fernandes - fbf2 Juliano Rabelo - jcbr Flávia Barros – fab (participação especial)

Documents

CIn-UFPE1 UML Uma linguagem unificada de modelagem Visão Geral

Documents

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1 Análise e Projeto de Sistemas Modelagem de Requisitos com Casos de Uso

Documents

CIn/UFPE – IN1008 – Projeto Conceitual de Banco de Dados 1

Documents

DI-UFPE1 Sistemas CASE Integração de Ferramentas CASE

Documents

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/38 Análise e Projeto de Sistemas Introdução à Análise e ao Projeto de Software

Documents

CIn-UFPE1 Introdução à Qualidade de Software Alexandre M. Lins de Vasconcelos Centro de Informática - UFPE amlv@cin.ufpe.br

Documents

Rede cin - institucional

Documents

CIn/UFPE – Projeto Conceitual de BD - Prof. Robson Fidalgo 1/63in1008/aulas/ProjetoBD_ParteI... · 2009. 3. 3. · CIn/UFPE – Projeto Conceitual de BD - Prof. Robson Fidalgo 3/63

Documents

CIn-UFPE1 Recuperação Inteligente de Informação Agrupamento de Texto

Documents

CIn-UFPE1 Mineração da Web Recuperação de Informação Modelos de Recuperação de Documentos Parte 2 Flávia Barros

Documents

Luis Fernando Sayão CNEN/CIN · luis fernando sayão cnen/cin. projeto de pesquisa? publicaÇÃo dados de pesquisa dados de pesquisa sÃo muito suscetÍveis a perdas biblioteca convencional

Documents

CIn/UFPE – IN1008 – Projeto Conceitual de Banco de Dados - Prof. Robson Fidalgo 1

Documents

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/58 Análise e Projeto de Sistemas...

Documents

©2008, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/45 Análise e Projeto de Sistemas if718 Augusto Sampaio 2008.2 Em co-autoria com

CIn-UFPE1 Recuperação de Informação Preparação do documentos Flávia Barros

Cin - Interiores

CIn-UFPE1 Recuperação de Informação Eduardo Amaral - efas Frederico Fernandes - fbf2 Juliano Rabelo - jcbr Flávia Barros – fab (participação especial)

CIn-UFPE1 UML Uma linguagem unificada de modelagem Visão Geral

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1 Análise e Projeto de Sistemas Modelagem de Requisitos com Casos de Uso

CIn/UFPE – IN1008 – Projeto Conceitual de Banco de Dados 1

DI-UFPE1 Sistemas CASE Integração de Ferramentas CASE

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/38 Análise e Projeto de Sistemas Introdução à Análise e ao Projeto de Software

CIn/UFPE – Projeto Conceitual de Banco de Dados – Prof. Robson Fidalgo 1

CIn-UFPE1 Mineração na Web Introdução a Recuperação de Informação Flávia Barros fab@cin.ufpe.br

CIn- UFPE 1 Paradigmas da IA Jacques Robin Geber Ramalho CIn-UFPE

CIn- UFPE Aprendizagem Simbólica Geber Ramalho Jacques Robin Francisco Carvalho CIn-UFPE

CIn-UFPE1 Introdução à Qualidade de Software Alexandre M. Lins de Vasconcelos Centro de Informática - UFPE amlv@cin.ufpe.br

Rede cin - institucional

CIn/UFPE – Projeto Conceitual de BD - Prof. Robson Fidalgo 1/63in1008/aulas/ProjetoBD_ParteI... · 2009. 3. 3. · CIn/UFPE – Projeto Conceitual de BD - Prof. Robson Fidalgo 3/63

CIn-UFPE1 Recuperação Inteligente de Informação Agrupamento de Texto

CIn-UFPE1 Mineração da Web Recuperação de Informação Modelos de Recuperação de Documentos Parte 2 Flávia Barros

Luis Fernando Sayão CNEN/CIN · luis fernando sayão cnen/cin. projeto de pesquisa? publicaÇÃo dados de pesquisa dados de pesquisa sÃo muito suscetÍveis a perdas biblioteca convencional

CIn/UFPE – IN1008 – Projeto Conceitual de Banco de Dados - Prof. Robson Fidalgo 1