Visão Geral e Conceitos. Copyright © 2006 Qualiti. Todos os direitos reservados. Qualiti Software Processes Análise e Projeto OO com UML e Padrões| 2

Visão Geral e Conceitos

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Qualiti Software ProcessesAnálise e Projeto OO com UML e Padrões| 2

ObjetivosApresentar os princípios e conceitos de orientação a objetos com a notação UML correspondenteImportância de processos de software e padrões

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Princípios básicos de OOModelagem centrada em dados Por que não funções?

Potencialmente, embutem características como Abstração Encapsulamento e information hiding modularidade Extensibilidade (herança) Polimorfismo

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


AbstraçãoConstrução de um modelo para representação de uma realidade

Concentração nas características essenciais, gerenciando complexidade

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


EncapsulamentoAgrupa elementos relacionados em uma unidade sintática (cápsula, módulo, classe, pacote, ...)

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Information hidingElimina dependência de implementação, escondendo-a do clienteUso de interfacesImplementado via mecanismos de controle de visibilidade Ex.: elementos privados em classes

Java

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Número Saldo

21.342-7 875,32

Crédito

Débito

Exemplo: objeto conta bancária

Encapsulamentoagregação de

elementos

Information hidingocultamento de

elementos

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Modularidade

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


ModularidadeDecomposição de um problema em partes menores, para gerenciar complexidadeCada conceito independente deve ser representado por um módulo (abstração)Construção de módulos desacoplados e coesosDividir para conquistar ...

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Herança

Figura

RetânguloTriângulo

Polígono

ContaEspecialPoupança

Conta

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


HerançaCriação de hierarquias de abstraçãoBase conceitual para permitir extensibilidade do softwareReuso de código e comportamento (subtipo)Herança comportamental (behavioural inheritance)Referência clássica: A behavioral notion of subtyping (Liskov & Wing)

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


PolimorfismoLinguagens polimórficas permitem que valores e identificadores (variáveis e operações) possuam mais de um tipoHá vários tipos de polimorfismo: Paramétrico, de inclusão, overloading e

coerção Referência clássica: On understanding types, data abstraction and polymorphism (Cardelli & Wegner)

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Polimorfismo de inclusão Herança define polimorfismo Objeto da subclasse usado no lugar

do objeto da classe Exemplo: uso de poupança em

contextos onde contas são esperadas

Interfaces também definem polimorfismo Reuso de tipo, mas não de código

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Polimorfismo real ou paramétrico

Forma mais pura de polimorfismoO mesmo objeto ou operação usada uniformemente em diferentes contextos (tipos só determinados em tempo de execução)Exemplo: generics em Java 1.5

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Polimorfismo via overloading e coerção

Overloading permite o uso do mesmo nome para vários elementos semânticos Exemplo: métodos ou construtores

em JavaCoerção é semelhante, mas inclui conversão implícita de tipos Exemplo: soma envolvendo um

operando inteiro e outro real

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Elementos básicos de OO em UML

ObjetoClasseAtributoOperaçãoInterfaceComponentePacoteSubsistemaRelacionamentos

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Objeto em UML

: Conta

contaSaque :Conta

contaSaqueApenas o nome daclasse

Apenas o nome doobjeto

Nome da classe e doobjeto

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Classe em UML

Conta

Nome da Classe Conta

Atributos Operações

numerosaldo

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

estrutura

comportamento

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Atributo e cenários em UML

: Conta

numero = 23.025-1saldo = 500,00

: Conta

numero = 21.342-7saldo = 875,32

Conta

numero: Stringsaldo: Real

Valor do Atributo

Objeto

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Operação em UML

Conta

credito(valor:Real)debito(valor:Real)getSaldo(): RealgetNumero(): String

Especificação das operações

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Visibilidade

Marcações de acesso podem ser usadas para especificar o tipo de acesso permitido aos atributos e operações

+ público # protegido - privado

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


InterfaceInterfaces definem um tipo especificando apenas a assinatura de seus métodosInterfaces não possuem atributos e seus métodos não têm corpoClasses, subsistemas e componentes implementam interfaces provêem implementação para os métodos

especificados em uma interface

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Exemplo: Independência do meio de armazenamento

Isolando as coleções de negócio de mudanças na coleção de dados correspondente

RepositorioContasBDR RepositorioContasOO

CadastroContas

<<interface>>RepositorioContas

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Interface em UML: notação alternativa

RepositorioContas

Relacionamentos de realização

RepositorioContasOO

RepositorioContasXML

RepositorioContasBDR

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Classe abstrataClasse abstrata não possui instânciaEm geral, possui pelo menos um método abstratoMétodos abstratos não têm corpo subclasses não abstratas são obrigadas

a fornecer uma implementação para eles

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Classes, Interfaces e Classes Abstratas

Classes

• Atributos• Métodos

Classes Abstratas

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

Interfaces

• Assinaturas dos métodos

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


ComponenteParte não trivial, 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 de tempo de execução

um componente executável

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Componente em UML

Interface doComponente

Arquivo fonte<<DLL>>

Componente<<EXE>>Arquivo

executável

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


PacoteMecanismo para organizar elementos em gruposFacilita entendimento do sistemaFavorece modularidade e reuso em larga escalaEssencial para estruturar sistemas complexos

nome do pacote

nome do pacote

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Coesão e AcoplamentoAcoplamento é a medida de quão conectadas duas classes são

Coesão é a medida de quão auto-contida uma classe é

Sistemas devem ter baixo acoplamento e alta coesão

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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

Realiza uma ou mais interfaces, que definem o seu comportamento

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Subsistema em UML

Subsistema

Interface

Realização

<<subsystem>>

Nome do subsistema

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Subsistemas e Componentes

Ambos encapsulam um comportamento modelado por interfacesSubsistemas representam componentes no modelo de projetoComponentes são a realização física dos subsistemas

Projeto

Implementação

Nome do componente

<<subsystem>>Nome do subsistema

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


RelacionamentosAssociação simples agregação composiçãoDependência GeneralizaçãoRealização

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


AssociaçãoRelação estrutural entre classes

Pessoa

Pessoa Empresa

Empresa

trabalha

Associação

Nome da associação

Classe

Empregado Empregador

Papéis

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


AgregaçãoTipo especial de associaçãoRelacionamento todo-parteO todo possui um nível de abstração maior que a parte

DepartamentoEmpresa

Todo Parte

Agregação

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


ComposiçãoTipo especial de agregaçãoRelação de posse mais forteO todo é responsável pela criação da parteA parte não vive sem o todoNão permite compartilhamento

DepartamentoEmpresa

Todo Parte

Composição

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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

Como você modelaria: Dependente e Funcionário? Pedido e Item do pedido? Funcionário e Cartão de ponto? Carro, Roda, Direção e Carburador?

Na dúvida, use agregação!

Na dúvida, use associação!

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


DependênciaRelacionamento não estrutural (uso) mais fraco que associação

Uma dependência entre dois elementos indica que mudança em um elemento pode causar mudanças no outro

CartãoLeitoraCartao

lerCartao (cartao) Relacionamentode Dependência

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


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

Classe

Pacote

PacoteFornecedor

ComponenteFornecedorCliente

PacoteClienteDependência

Fonte: Rational

FornecedorCliente

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Exercício - Relacionamentos

Modele os relacionamentos existentes entre as classes abaixo:

Universidade Departamento

Aluno Disciplina Professor

Curso

Turma

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Multiplicidade

Multiplicidade define quantos objetos participam do relacionamento O número de instâncias de uma classe

relacionadas a uma instância de outra classe

Especificado em cada uma das pontas da associação

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Tipos de MultiplicidadeNão especificadaExatamente umZero ou maisMuitos (mesmo que 0..*)Um ou maisZero ou umIntervalo determinadoValores múltiplos

1

0..*

*

1..*

0..1

2..4

2, 4..6

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Exemplo: Multiplicidade

PessoaEmpresa

Multiplicidade

1..*1

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Navegação

Especifica a direção da associaçãoAssociações e agregações são bidirecionais por default, mas é desejável que a navegação seja restringida a apenas uma direçãoAssociações bidirecionais são mais difíceis de implementar

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Exemplo: Navegação

PessoaEmpresa

Navegação

1..*1

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Exercício - MultiplicidadeAcrescente a multiplicidade nos relacionamentos encontrados no exercício anterior

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Generalização

Relacionamento entre classes onde uma classe compartilha a estrutura (atributos e relacionamentos) e comportamento (operações) de outras classesDefine uma hierarquia de abstraçõesRelacionamento “é um tipo de” (is-a-kind-of) Herança comportamental

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Generalização

Uma subclasse pode adicionar atributos, operações e

relacionamentos redefinir operações herdadas

Tipos de herança: simples e múltipla

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Herança Simples

Classes herdando de apenas uma outra classe

Círculoraiocentrodesenhar()

Retânguloverticesdesenhar()diagonal()

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

Subclasses

Superclasse(pai)

Relacionamentode Generalização

Quadrado

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Herança Múltipla

Classes herdando de mais de uma classe

Mamífero AnimalVoadorHerançamúltipla

Cachorro Gato Morcego Passarinho Gaviao

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Herança Múltipla

O que acontece quando as superclasses possuem o mesmo método (métodos com o mesmo nome? O que acontece quando se tenta executar um método que não está definido na subclasse? Em que hierarquia de superclasses deve-se procurar o método?

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Realização

Realização

SubsistemaClasse

Caso de uso

Indica que um elemento serve como contrato que o outro deve seguir

Exemplos:

Componente

Realização de Caso de uso

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Exercício - ArquiteturaDefina uma arquitetura simplificada da aplicação bancária (QIB)

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Mecanismos adicionais de UML

EstereótiposNotasPropriedades (Tagged values)RestriçõesOCL (Object Constraint Language)

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Estereótipos

Mecanismo utilizado para estender os elementos de UMLDefine um novo modelo de elemento em termos de outro já existente Como criando um novo ícone utilizando a notação <<novo_elemento>>

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Estereótipos - Exemplo

Classes de fronteira:

ClasseFronteira

<<boundary>>ClasseFronteira

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


NotasAnotação utilizada para adicionar informação a diagramas Pode ser afixionada a qualquer elemento de UML Pode ser ligada a um elemento com uma linha tracejada

Exemplo:

LeitorCartao

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

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Propriedades (Tagged Values)

Servem para estender elementos UML, adicionando informações sobre elesExemplos já definidos em UML: Persistence Location (ex: no cliente, no servidor)

Você pode criar suas próprias propriedades

Cliente{persistence}

LeitorCartao {location=server}

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Restrições

Pessoa Empresa{subset}

funcionários

diretores

1..* 1

3 1

Usadas para criação de novas regras sobre elementos do modeloOu modificação de regras existentes

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


OCL (Object Constraint Language)

Empresa

É uma linguagem usada para definir restrições sobre elementos do modelo ou modificação de restrições existentes Invariantes de classe Pré e pós-condições de operações

context Empresainv diretoresNecessarios:self.diretor->size() == 3

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Diagramas UML

Diagramas usados no curso serão apresentados sob demanda Seqüência Colaboração Classes Pacotes Estados Estrutura

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Qualiti Software Processes63

Processos e PadrõesOrientação a objetos e DBC são paradigmas promissores, mas Reuso Extensibilidade Escalabilidade ...

exigem Processos Técnicas Disciplina Experiências anteriores de sucesso (padrões)!

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Analisar Casos de Uso

Revisar Projeto

Projetar Arquitetura

Projetista deBanco de Dados

Arquiteto de Software

Revisor de projeto

Projetar Casos de Uso

Projetar Subsistemas

Projetar Base de Dados

Analista deSistemas

Fluxo de Análise e Projeto

decisões doarquiteto

<<subsystem>>

CheckList bla bla bla blabla

Projetar classes

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Padrões de Projeto e Arquiteturais

Projetistas experientes (re)utilizam soluções bem sucedidas no passadoPadrões sistematizam soluções, incluindo

• Nome• Problema• Solução• Conseqüência• Exemplo, ...

Durante as duas última décadas, surgiu uma “comunidade” voltada a padrões

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.

Qualiti Software Processes

Exemplo: Padrão Fachada

66

Fachada

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


Anti-PadrõesSão uma maneira de documentar soluções recorrentes que não tiveram sucesso

• Podem também incluir soluções re-trabalhadas que sejam efetivas

Respostas dos Exercícios

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


RelacionamentosResposta do exercício


Aluno Disciplina

Professor

Curso

Turma

Copy

right

© 2

006

Qual

iti. T

odos

os d

ireito

s res

erva

dos.


MultiplicidadeResposta do exercício


Aluno Disciplina

Professor

Curso

Turma

1..3

**

*1*

*

1

1

*

*1

1

1

*

*

Documents

Visão Geral e Conceitos. Copyright © 2006 Qualiti. Todos os direitos reservados. Qualiti Software Processes Análise e Projeto OO com UML e Padrões| 2