Análise e Projeto
Orientados a Objeto
com UML e Padrões
Parte I
Introdução
Prof. Msc. Emerson Silas Dória
1
Aplicando UML, Padrões e
APOO

Objetivo



LPOO são um primeiro passo necessário, mas
insuficiente
Outros recursos importantes




Desenvolver habilidades práticas em APOO para a
criação de sistemas de software bem projetados,
robustos e modificáveis.
processo de desenvolvimento
padrões
UML
Práticas através de estudo de caso detalhado
Prof. Msc. Emerson Silas Dória
2
Atribuindo Responsabilidades

Saber a maneira adequada de atribuir
responsabilidades a componentes de
software é a habilidade mais importante
na APOO


Mais difícil de dominar
Afeta com mais profundidade a robustez,
modificabilidade e reusabilidade do sistema
Prof. Msc. Emerson Silas Dória
3
Atribuindo Responsabilidades


Padrões descrevem princípios
fundamentais para auxiliar na atribuição
de responsabilidades, ex: GRASP
Saber identificar objetos ou abstrações
adequados é a segunda habilidade mais
importante
Prof. Msc. Emerson Silas Dória
4
O que são Análise e Projeto?
Análise — “o quê”
investigação do problema e
dos requisitos
Quais os processos de
negócio relacionados com o
seu uso?
Projeto — “como”
descrição de uma solução
lógica
Como exatamente o software
irá capturar e registrar
informações?
Prof. Msc. Emerson Silas Dória
5
Conflito de Terminologias

Termos “Análise” e “Projeto” não são fixos,
mas usados ao longo de um contínuo
Mais orientado a análise


Mais orientado a projeto
Significados variam de metodologia para
metodologia
Distinção é útil na prática, mas debater
definições rígidas não é construtivo
Prof. Msc. Emerson Silas Dória
6
O que é APOO?


A essência da APOO é enfatizar a consideração de
um domínio de problema e uma solução lógica,
segundo a perspectiva de objetos (coisas,
conceitos e entidades)
O que é Análise OO?


Ênfase na descoberta e na descrição dos objetos.
O que é Projeto OO?

Ênfase na definição de elementos lógicos de software.
Prof. Msc. Emerson Silas Dória
7
Representação de um conceito
na APOO
Conceito
de domínio
Representação
na análise
Livro
Representação
no projeto
Livro
título
título
imprimir()

Exemplo: O
conceito “Livro”
em um sistema
de biblioteca.
Representação
no código
Prof. Msc. Emerson Silas Dória
public class Livro
{
public void imprimir();
private String titulo;
}
8
Uma analogia — Organizando
os negócios de uma empresa
Analogia de
Negócio
APOO
Documentos
Associados
Quais são os processos Análise de requisitos
de negócio?
Casos de uso
Quais são os papeis
dos empregados?
Análise do domínio
Modelo conceitual
Quem é responsável
por o quê? Como eles
interagem?
Atribuição de
responsabilidades,
projeto das interações
Diagramas de classes
de projeto, diagramas
de colaboração
Prof. Msc. Emerson Silas Dória
9
Jogo de Dados
Exemplo

Objetivo: ganha o jogo o jogador que
rolar dois dados e tirar sete
Processo de Software OO
Definir Casos
de Uso
Definir Modelo
Conceitual
Definir Diagramas
de Interação
Prof. Msc. Emerson Silas Dória
Definir Diagramas
Classes de Projeto
10
Jogo de Dados
Exemplo

continuação...
Casos de Uso

Descrições narrativas de processos do
domínio no formato de prosa estruturada
Caso de uso: Jogar
Jogador
Atores:
Este caso de uso começa quando
Descrição:
o jogador rola os dados. Se o total
dos dados for sete, o jogador ganha;
do contrário, ele perde.
Prof. Msc. Emerson Silas Dória
11
Jogo de Dados
Exemplo

continuação...
Modelo Conceitual

Conceitos, atributos, e associações que são
considerados importantes no domínio do
problema
Jogador
1
lança
Dado
2
ValorDaFace
Nome
1
2
joga
1
JogoDeDados
1
inclui
Prof. Emerson Silas Dória - FIPP
12
Jogo de Dados
Exemplo

continuação...
Modelo Conceitual

Um modelo conceitual descreve conceitos
do mundo real, não componentes de
software!
Prof. Msc. Emerson Silas Dória
13
Jogo de Dados
Exemplo

continuação...
Diagramas de Interação
Diagrama de Colaboração


Alocação de responsabilidades para objetos e
ilustração de como eles interagem via mensagens
Mostram o fluxo de mensagens entre instâncias e a
invocação de métodos
Jogar( )
:Jogador
1: r1 := Lançar( )
d1 :
Dado
2: r2 := Lançar( )
d2 :
Dado
Prof. Msc. Emerson Silas Dória
14
Jogo de Dados
Exemplo

continuação...
Diagramas de Interação
Diagrama de Seqüência
:JogoDeDad
os
d1:Dado
d2:Dado
Jogar()
Lançar( )
vf1:=ObterValorDaFace( )
Lançar( )
vf2:=ObterValorDaFace( )
Prof. Msc. Emerson Silas Dória
15
Jogo de Dados
Exemplo

continuação...
Diagramas de Classes de Projeto


Como os objetos (de software) se conectam?
Quais são os métodos de uma classe?
Versão 1
Jogador
1
2
Dado
Nome
Valordaface:int
Jogar( )
Lançar( )
JogoDeDados 1
2
Inicializar( )
Prof. Msc. Emerson Silas Dória
16
Jogo de Dados
Exemplo

continuação...
Diagramas de Classes de Projeto


Como os objetos (de software) se conectam?
Quais são os métodos de uma classe?
Versão 2
JogoDeDados 1
d1,d2:Dado
Jogar( )
2
Dado
Valordaface:int
Lançar( )
ObterValorDaFace():int
Prof. Msc. Emerson Silas Dória
17
APOO X APE

Metodologias mais antigas, como Análise e Projeto Estruturados,
baseiam-se em outras dimensões de decomposição
Sistema de
Biblioteca
A&P Orientados a Objeto
A&P Estruturados
decomposição por objetos ou conceitos
decomposição por funções ou processos
Catálogo
Bibliotecário
Livro
Biblioteca
Sistema
Registra
Empréstimos
Prof. Msc. Emerson Silas Dória
Adiciona
Recursos
Reporta
Multas
18
A Linguagem de Modelagem
Unificada



A UML é a linguagem padrão de diagramação para
visualizar os resultados da análise e projeto
A notação (a própria UML) é relativamente trivial
Muito mais importante: habilidade para modelar
com objetos


Só aprender a notação UML não ajuda
A UML não é



um processo ou metodologia
APOO
regras de projeto
Prof. Msc. Emerson Silas Dória
19
Origem e UML
Evolução
da
UML
1.1
Industrialização
(Set’97)
UML 1.0
Parceiros
da UML
Padronização
(Jan’97)
UML 0.9 & 0.91
Unificação II
(Out’96)
Unified Method 0.8
Booch’93
Outros
métodos
Booch’91
Unificação I
(Out’95)
OMT-2
OMT-1
OOSE
Prof. Msc. Emerson Silas Dória
Fragmentação
20
Processo de Desenvolvimento


Um processo de desenvolvimento de software
é um método para organizar as atividades
relacionadas à criação, entrega e manutenção
de sistemas de software.
A habilidade de saber como criar um bom
projeto é mais importante do que seguir um
método ou processo oficial.
Prof. Msc. Emerson Silas Dória
21
Processo de Desenvolvimento



Essa habilidade é adquirida dominando-se um
conjunto de princípios e heurísticas para
identificar e abstrair um conjunto relevante
de objetos e atribuir responsabilidade a eles.
Em essência, a descrição de um processo
inclui atividades que vão da análise dos
requisitos até a instalação.
O material apresentado (e a disciplina) não vão tratar
de atividades tais como: concepção, planejamento,
gerenciamento, documentação e teste.
Prof. Msc. Emerson Silas Dória
22
Processo de Desenvolvimento

UML padroniza artefatos e notação, mas
não define um processo-padrão, razões:


Aumentar a probabilidade de aceitação
ampla de uma notação de modelagem
padronizada;
Variação significativa naquilo que constitui
um processo apropriado;
Prof. Msc. Emerson Silas Dória
23
Processo Iterativo Simplificado



Planejar e Elaborar: planejamento, definição
de requisitos, protótipo, etc;
Construir: a construção do sistema;
Instalar: a colocação em uso do sistema;
instalar
planejar
construir
elaborar
Prof. Msc. Emerson Silas Dória
24
Desenvolvimento Iterativo



Um ciclo de vida iterativo envolve a repetição
de vários ciclos de planejamento, elaboração,
construção e instalação.
O sistema cresce pela adição de novas
funções (e refinamento das existentes) em
cada ciclo iterativo.
Cada ciclo ataca um pequeno conjunto de
requisitos.
Prof. Msc. Emerson Silas Dória
25
Desenvolvimento Iterativo
Plan. &
Elaboração
Ciclo de
Desenv. 1
Ciclo de
Desenv. 2
Refin.
Plano
Construção
Implantação
...
Sinc.
Artefatos
Análise
Projeto
Prof. Msc. Emerson Silas Dória
Impl.
Teste
26
Casos de Uso e CVIs

Um caso de uso é uma descrição textual
(narrativa) de um processo do domínio.
Exemplo: “Emprestar um livro da biblioteca”


Os ciclos de desenvolvimento iterativos são
organizados com base nos requisitos de um
conjunto de casos de uso.
Os casos de uso devem ser classificados e os
mais importantes devem ser atacados nos
CVIs iniciais, bem como requisitos não
funcionais.
Prof. Msc. Emerson Silas Dória
27
CVIs baseados em Casos de Uso
Ciclo de
Desenvolvimento 1
Ciclo de
Desenvolvimento 2
Ciclo de
Desenvolvimento 3
Caso de uso A
Versão
Simplificada
-----
Caso de uso A
Versão
Completa
-----
Caso de uso B
...
Caso de uso C
Prof. Msc. Emerson Silas Dória
28
a:permanente
Planejar e Elaborar









b:opcional
c: pode atrasar
d: qq ordem
Definir plano inicial
Criar Relatório de Investigação Preliminar
Definir Requisitos
Registrar termos no glossário (a)
Implementar protótipo (b,d)
Definir casos de uso(alto nível e essenciais)
Definir modelo conceitual inicial
Definir a arquitetura inicial do sistema(a,c,d)
Refinar o plano
Prof. Msc. Emerson Silas Dória
29
Análise







Definir os casos de uso essenciais (se ainda
não foi feito)
Refinar os diagramas de casos de uso
Refinar o modelo conceitual
Refinar o glossário (permanente)
Refinar os Diagramas de Seqüência do
Sistema
Definir os contratos de operação
Definir os diagramas de estado (opcional)
Prof. Msc. Emerson Silas Dória
30
Projeto






Definir casos de uso reais
Definir Relatórios, Interface e Storyboards
Refinar a arquitetura do sistema (qq ordem)
Definir diagramas de interação
Definir diagramas de classe do projeto (em
paralelo com diagramas de interação)
Definir esquema da base de dados
Prof. Msc. Emerson Silas Dória
31
Casos de Uso e CVIs

Na fase de planejamento e elaboração,
criar todos os casos de uso de alto
nível, mas refinar apenas os mais
críticos e importantes, deixando os
demais para outros CVIs.
Prof. Msc. Emerson Silas Dória
32
Definição de Modelos e Artefatos



O mundo real é complexo e cheio de
detalhes, por isso ele deve ser decomposto
em partes, chamadas de modelos, que
descrevem e abstraem aspectos essenciais
dos sistemas.
Modelos são compostos de outros modelos,
que são chamados de artefatos - diagramas e
documentos – e são visualizados em visões.
Os modelos podem enfatizar aspectos
dinâmicos e estáticos do sistema.
Prof. Msc. Emerson Silas Dória
33
Definição de Modelos e Artefatos


Modelo de Análise: modelos
relacionados a uma investigação do
domínio e do espaço do problema, mas
não à solução.
Modelo de Projeto: modelos
relacionados à solução lógica.
Prof. Msc. Emerson Silas Dória
34