Fluxo de Análise e Projeto Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados. Engenharia de Software Alexandre Vasconcelos, André Santos,

Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.

Fluxo de Análise e Projeto

Engenharia de Software

Alexandre Vasconcelos, André Santos, Augusto

Sampaio, Hermano Moura, Paulo Borba



Tópicos

1 - Visão Geral de Orientação a Objetos e UML

2 - Visão Geral do Fluxo de Análise e Projeto

3 - Atividade Analisar de Caso de Uso

4 - Atividade Projetar Arquitetura

5 - Atividade Projetar Caso de Uso

6 - Atividade Projetar Subsistema

7 - Atividade Projetar Classe

Aspectos de Concorrência, Distribuição e Projeto de Base de Dados não serão abordados



Referências

• Descrição do fluxo de análise e projeto – Link para o RUP a partir da página do curso

• Capítulos 8 e 9 do livro The Unified Software Development Process– Uma observação importante é que o CD do RUP

apresenta um único fluxo para análise e projeto, enquanto no livro são dois fluxos independentes

• The Unified Modeling Language User Guide– Introdução e consultas eventuais à notação de UML



1 - Visão Geral de Orientação a Objetos e UML



Objetivos

• Apresentar os princípios do paradigma de orientação a objetos

• Apresentar os conceitos de orientação a objetos com a notação UML correspondente



Princípios básicos de OO

• Abstração

• Encapsulamento

• Modularidade

• Herança



Abstração

• Construção de um modelo para representação de uma realidade

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



Abstração - Objetos do mundo real

cliente

gado

automóvel



Abstração - construção de um modelo para a realidade

Automovelmodelopreco...atualizaPreco()...



Encapsulamento

• Elimina dependência de implementação, escondendo-a do cliente

• Uso de interfaces

• Mudanças internas não têm impacto sobre os clientes



Encapsulamento - Objeto televisão



Número Saldo

21.342-7 875,32

Crédito

Débito

Encapsulamento: Objeto conta bancária



Modularidade

• Decomposição de um problema em pequenos pedaços, para gerenciar complexidade

• Cada conceito independente deve ser representado por um módulo

• Construção de módulos desacoplados

• Dividir para conquistar ...



Modularidade



Herança

• Criação de hierarquias de abstração

• Permite ordenar hierarquias relacionadas

• Base conceitual para permitir extensibilidade do software

• Reuso de código e comportamento (subtipo)



Herança

Figura

RetânguloTriângulo

Polígono

ContaEspecialPoupança

Conta



Herança: Objeto poupança

Número Saldo

21.342-7 875,32

Crédito

Débito

R. Juros



Conceitos básicos de OO

• Objeto• Classe• Interface• Componente• Pacote• Subsistema• Relacionamentos



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



Classes de Objetos

• Quantas classes temos aqui?

Fonte: Rational



Classe de Contas Bancárias



Classe em UML

Conta

Nome da Classe Conta

Atributos

Operações

numerosaldo

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

estrutura

comportamento



Objeto

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

de software

• Possui comportamento, estado e identidade

• Exemplo: objetos conta e poupança apresentados



Objeto em UML

: Conta

ContaSaque :Conta

ContaSaqueApenas o nome daclasse

Apenas o nome doobjeto

Nome da classe e doobjeto



Objeto em UML

: ContaDeposito

numero = 23.025-1saldo = 500,00

: ContaSaque

numero = 21.342-7saldo = 875,32

Conta

numerosaldo

Valor do Atributo

Objeto



Polimorfismo

• Escondendo diferentes implementações através de uma única interface

Manufacturer BManufacturer CManufacturer A

Fonte: Rational

interface bem definida



Interface

• Interfaces formalizam polimorfismo

• Interfaces permitem o uso de arquitetura baseada em componentes

Relacionamento de realização

Círculo

Pirâmide

Cubo

DesenharMoverModificarTamanhoRotacionar

<<interface>>

Forma

Fonte: Rational



Exemplo: Repositório de Contas

ListaContas

RepositorioBDR

RepositorioBDOO

IncluirRemovercreditodebito

<<interface>>

Repositorio

Fonte: Rational



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

• Classes implementam interfaces– provêem implementação para os métodos especificados em

uma interface



Interface em UMLCírculo

Pirâmide

Cubo

DesenharMoverModificarTamanhoRotacionar

RepresentaçãoCanônica

Representaçãocom ícone

Forma

<<interface>> Forma

Círculo

Pirâmide

Cubo

Fonte: Rational



Classe 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– devem ser implementados em subclasses não

abstratas



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



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 de tempo de execução – um componente executável



Componente em UML

Source FileName

<<EXE>>Executable

Name

<<DLL>>Component

Name

Component Interface



Pacote

• Mecanismo para organizar elementos em grupos

• Facilita entendimento do sistema• Favorece modularidade e reuso

em larga escala

• Essencial para estruturar sistemas complexos

Package Name



Coesão e Acoplamento

• Acoplamento é a medida de quão conectadas duas classes são– cuidado com herança

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

• Sistemas devem ter baixo acoplamento e alta coesão – bom para manutenção



Subsistema

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

• Realiza uma ou mais interfaces, que definem o seu comportamento



Subsistema em UML

Subsistema

Interface

Realização

<<subsystem>>

Subsystem Name



Subsistemas e 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



Relacionamentos

• Associação– simples– agregação– composição

• Dependência

• Generalização

• Realização



Associação

• Relação estrutural entre classes

Pessoa

Pessoa Empresa

Empresa

trabalha

Associação

Nome da associação

Classe

Empregado Empregador

Papéis



Agregação

• Tipo especial de associação• Relacionamento todo-parte• O todo possui um nível de abstração maior que a parte

DepartamentoEmpresa

Todo Parte

Agregação



Composição

• Tipo especial de agregação

• Relação de posse mais forte

• O todo é responsável pela criação da parte

• A parte não vive sem o todo

DepartamentoEmpresa

Todo Parte

Composição



Dependência

• Relacionamento 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



Dependência

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

Classe

Pacote

PacoteFornecedor

Componente

Cliente Fornecedor

FornecedorCliente

PacoteClienteDependência

Fonte: Rational



Exercício - Relacionamentos

• Modele os relacionamentos existentes entre as classes abaixo:

Universidade Departamento

Estudante Disciplina Instrutor



Multiplicidade

• Multiplicidade 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 da associação



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



Exemplo: Multiplicidade

PessoaEmpresa

Multiplicidade

1..*1



Navegação

• Especifica a direção da associação• Associações e agregações são bidirecionais

por default, mas é desejável que a navegação seja restringida a apenas uma direção

• Associações bidirecionais são mais difíceis de implementar



Exemplo: Navegação

PessoaEmpresa

Navegação

1..*1



Exercício - Multiplicidade

• Acrescente a multiplicidade nos relacionamentos encontrados no exercício anterior.



Generalização

• Relacionamento entre classes onde uma classe compartilha a estrutura (atributos e relacionamentos) e comportamento (operações) de outras classes

• Define uma hierarquia de abstrações

• Relacionamento “é um tipo de” (is-a-kind-of)



Generalização

• Uma subclasse pode – adicionar atributos, operações e

relacionamentos– redefinir operações herdadas

• Tipos de herança: simples e múltipla



Herança Simples

• Classes herdando de apenas uma outra classe

Círculoraiocentro

desenhar()

Retânguloverticesdesenhar()diagonal()

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

Subclasses

Superclasse(pai)

Relacionamentode Generalização

Quadrado



Herança Múltipla

• Classes herdando de mais de uma classe

ObjetoVoador Animal

Herançamúltipla

Avião Helicóptero Pássaro Lobo Cavalo

Fonte: Rational



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?



Realização

Realização

SubsistemaComponenteClasse

Caso de uso Realização de Caso de uso

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

Exemplos:



Exercício - Generalização

• Modele a hierarquia de classes de uma aplicação bancária com contas correntes (contas comuns, sem cheque especial), poupanças e contas especiais (contas com certo crédito).



Mecanismos adicionais de UML

• Estereótipos

• Notas

• Propriedades (Tagged values)

• Restrições



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



Estereótipos - Exemplo

• Classes de fronteira:

ClasseFronteira

<<boundary>>ClasseFronteira



Notas

• Anotação utilizada para adicionar informação a diagramas– Pode ser associada 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 (Tagged Values)

• Servem para estender elementos UML, adicionando informações sobre eles• Exemplos já definidos em UML:

– Persistence– Location (ex: no cliente, no servidor)

• Você pode criar suas próprias propriedades Cliente

{persistence}LeitoraCartao

{location=server}



Paradigma de Orientação a Objetos

• Benefícios– Favorece modularidade, extensibilidade,

compatibilidade e reuso, suportando a evolução do sistema

– Aproxima-se do mundo real– Uso do mesmo conceito em todas as fases

do desenvolvimento



Respostas dos Exercícios



RelacionamentosResposta do exercício



vinculado

inscrito ministra

alocado no

coordena



MultiplicidadeResposta do exercício



vinculado

inscrito ministra

alocado no

coordena

* * * 1..*

0..11..*

0..1

1..*1..*

1..*1

1..*

* 1..*



GeneralizaçãoResposta do exercício

Conta-corrente

Conta

Poupança

Conta especial

Documents

Fluxo de Análise e Projeto Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados. Engenharia de Software Alexandre Vasconcelos, André Santos,