EP - UML - slide

Prévia do material em texto

03/03/2012
1
Parte 1
Introdução a orientação a Objetos
1
A estratégia de O-O para modelagem de sistemas baseia-se 
na identificação dos objetos (que desempenham ou sofrem 
ações no domínio do problema) e dos padrões de 
cooperação e interação entre estes objetos.
2
Orientação a 
Objeto
03/03/2012
2
Objeto
• Definição:
– Um conceito, uma abstração com significado específico em um 
contexto
• Propósito:
– representar uma entidade do mundo real
• Objetos possuem:
– Identidade
– Conjunto de características que determinam seu estado
– Comportamento específico definido por um conjunto de ações
3
Orientação a 
Objeto
4
Identidade: ‘Beija-flor Biju’
Características:
penas azuis
bico fino
vôo rápido
Comportamento:
voar
piar
Identidade: ‘Pessoa Mário’
Características:
olhos pretos
nasceu em 16/02/70
pesa 70kg
mede 1,70m
Comportamento:
andar
falar
comer
rir
Exemplo de Objetos
Orientação a 
Objeto
03/03/2012
3
5
Identidade: ‘Telefone da minha casa’
Características:
azul
número 576-0989
tone
Comportamento:
tocar
discar
Características:
cor amarela
placa LXY 7684
30 assentos
a diesel
Comportamento:
frear
andar
correr
buzinar
acelerar
Orientação a 
Objeto
6
Mário
Características
(estado)
Nome = Mário Sá
Nasc = 16/02/70
Salário = 3.000
InformarSalário
CalcularIdade
Identidade
Representação
Funcionário_Mário
Objeto
Orientação a 
Objeto
03/03/2012
4
Classe Pessoa
Objeto 
João
Objeto Ana
7
Diferença entre Classe e Objeto
Orientação a 
Objeto
8
Classe
Funcionário
Nome
Nasc
Salário
InformarSalário
CalcularIdade
Instâncias
(objetos)
Funcionário_Helena
Nome=Helena Reis
Nasc=28/01/1965
Salário = 4.000
InformarSalário
CalcularIdade
Funcionário_Mário
Nome=Mário Sá
Nasc=16/02/1970
Salário = 3.000
InformarSalário
CalcularIdade
Classe
Orientação a 
Objeto
03/03/2012
5
Classe
• Definição:
– Abstrações utilizadas para representar um conjunto de objetos com 
características e comportamento idênticos
• Uma classe pode ser vista como uma “fábrica de objetos”
• Objetos de uma classe são denominados “instâncias”
– Todos os objetos são instâncias de alguma classe
– Todos os objetos de uma classe são idênticos no que diz respeito a sua 
interface e implementação
9
Orientação a 
Objeto
• Descrevem as características das 
instâncias de uma classe
• Seus valores definem o estado do 
objeto
• O estado de um objeto pode mudar 
ao longo de sua existência
• A identidade de um objeto, 
contudo, nunca muda
Funcionário
Nome
Nasc
Salário
InformarSalário
CalcularIdade
Funcionário_Helena
Nome=Helena Reis
Nasc=28/01/1965
Salário = 4.000
InformarSalário
CalcularIdade
Funcionário_Mário
Nome=Mário Sá
Nasc=16/02/1970
Salário = 3.000
InformarSalário
CalcularIdade
10
Atributos
Orientação a 
Objeto
03/03/2012
6
Mensagens
• Objetos são entidades independentes que necessitam se comunicar
– Para obter informações ou ativar o comportamento de objetos, é 
preciso enviar-lhes mensagens
– Ao receber uma mensagem, o objeto busca em seu protocolo um 
método que irá responder a tal mensagem
• Objetos só reagem a mensagens que fazem parte das ações do 
protocolo de sua classe
� Troca de mensagens: Paradigma de comunicação entre objetos
11
Orientação a 
Objeto
12
Funcionário
Nome
Nasc
Salário
InformarSalário
CalcularIdade
Funcionário_Helena
Nome=Helena Reis
Nasc=28/01/1965
Salário = 4.000
InformarSalário
CalcularIdade
Funcionário_Helena
Nome=Helena Reis
Nasc=28/01/1965
Salário = 4.000
InformarSalário
CalcularIdade
?
ERRO!
4000 Informar 
Salário?
Calcular 
Desconto
?
Mensagens
Orientação a 
Objeto
03/03/2012
7
Serviços/Métodos
• Representam o comportamento das instâncias de uma classe
• Correspondem às ações das instâncias de uma classe
Funcionário
Nome
Nasc
Salário
InformarSalário
CalcularIdade
Funcionário_Helena
Nome=Helena Reis
Nasc=28/01/1965
Salário = 4.000
InformarSalário
CalcularIdade
Funcionário_Mário
Nome=Mário Sá
Nasc=16/02/1970
Salário = 3.000
InformarSalário
CalcularIdade
4000
3000
Informar 
Salário?
13
Orientação a 
Objeto
Serviços/Métodos
• Um método é a implementação de uma operação
– possuem argumentos, variáveis locais , valor de retorno, etc
14
Orientação a 
Objeto
03/03/2012
8
• Conceito que expressa similaridades entre classes
• Estabelecem relacionamentos de generalização-especialização (“é-um”) 
entre classes
• Permitem estabelecer hierarquias de classificação
15
Herança
Orientação a 
Objeto
16
Funcionário_Helena
Nome=Helena Reis
Nasc=28/01/1965
Salário = 4.000
InformarSalário
CalcularIdade
Funcionário
Nome
Nasc
Salário
InformarSalário
CalcularIdade
Gerente
Nome
Nasc
Salário
Projeto
InformarProjeto
InformarSalário
CalcularIdade
Gerente_Mário
Nome=Mário Sá
Nasc=16/02/1970
Salário = 3.000
InformarSalário
CalcularIdade
Projeto = SAP
InformaProjeto
Orientação a 
Objeto
03/03/2012
9
17
Subclasse
(características 
específicas)
Superclasse
(características comuns)
Funcionário_Helena
Nome=Helena Reis
Nasc=28/01/1965
Salário = 4.000
InformarSalário
CalcularIdade
Funcionário
Nome
Nasc
Salário
InformarSalário
CalcularIdade
Gerente
Projeto
InformarProjeto
Gerente_Mário
Nome=Mário Sá
Nasc=16/02/1970
Salário = 3.000
Projeto = SAP
InformarSalário
CalcularIdade
InformarProjeto
Todo objeto Gerente “é um” objeto Funcionário
17
Orientação a 
Objeto
Parte 2
UML - Conceitos
18
03/03/2012
10
• UML é uma linguagem para:
– Especificar
– Visualizar
– Construir 
.... artefatos de sistemas de software
• Oferece uma notação para a modelagem de sistemas seguindo 
os conceitos da orientação a objetos.
A UML é uma linguagem para modelagem; ela não guia o desenvolvedor 
em como fazer a análise e projeto orientado a objetos, ou qual processo 
de desenvolvimento deve ser seguido
19
UML
Histórico
• Inicialmente, um esforço de integração dos principais autores de 
métodos OO:
– Ivar Jacobson, Grady Booch e Jim Rumbaugh
• A partir de 1997, foi submetida como candidata a padrão à OMG 
(Object Management Group)
• A UML atualmente está na versão 2
• www.uml.org 
20
UML
03/03/2012
11
Propósitos
• Prover uma linguagem de modelagem visual potente e 
significativa, que represente os conceitos básicos de modelagem 
aceitos por vários métodos e ferramentas
• Prover mecanismos de extensão e especialização que permitam a 
ampliação dos conceitos básicos
• Ser independente de linguagem de programação e de processo de 
desenvolvimento
21
UML
22
• Diferentes aspectos do 
sistema a ser modelado
• Modelo completo só através 
de várias visões
• Metodologias diferentes 
usam os diagramas para 
compor diferentes visões
• Gráficos que descrevem o 
conteúdo de uma visão
• Uma visão pode ser 
composta por vários 
diagramas
Visões Diagramas
UML
03/03/2012
12
23
• Visão Externa
– Diagrama de Casos de Uso 
• Visão Estrutural (Estática)
– Diagrama de Classes
– Diagrama de Objetos
• Visão Comportamental
(Dinâmica)
– Diagrama de Estado
– Diagrama de Atividade
• Visão de Interação
– Diagrama de Sequência
– Diagrama de Colaboração
• Visão da Arquitetura
(Implementação)
– Diagrama de 
Componentes
– Diagrama de Implantação
– Diagrama de Pacotes
Visões e Diagramas da UML
UML
UML – Caso de Uso
24
03/03/2012
13
Simboliza um negócio, onde são definidas as responsabilidades do 
sistema e as do ambiente.Sistema de NegócioAmbiente Fronteira
25
Casos de Uso - Sistema de Negócio
UML
26
Um caso de uso é uma seqüência de ações que um ator
executa em um sistema com um propósito específico.
Caso de Uso - Definição
UML
03/03/2012
14
27
• Externo ao sistema
• Papel de alguém 
• Abstração de alguma pessoa ou 
coisa que utiliza o sistema, 
inclusive outro sistema
• Tudo aquilo que interage com o 
sistema e que interessa ser 
modelado
Caso de Uso - Ator
UML
28O nome do caso de uso: verbo no infinitivo + substantivo.
Vendedor
Registrar Contrato
Cadastrar Cliente
Adquirir
Suprimentos
Gerente
Caso de Uso - Diagrama
UML
03/03/2012
15
29
Caso de Uso - Descrição
A UML não especifica um formato rígido para a modelagem da
descrição de casos de uso, somente para sua diagramação. Ela
pode ser alterada para atender a necessidades específicas,
aumentar a clareza da documentação ou melhorar a
comunicação. Normalmente as descrições são construídas
como um texto explicativo ou passos de um procedimento, em
português.
UML
30
Caso de Uso – Descrição não expandida
Caso de Uso: Fechamento de Conta
Atores: Caixa
Descrição: A partir da solicitação feita por um cliente, garçom se 
identifica e informa ao sistema o número da mesa 
que deseja ter a conta fechada. Ao final, o sistema 
apresentará a relação de produtos consumidos e seus 
valores, garçom que realizou o atendimento e o 
tempo de permanência do cliente no restaurante.
UML
03/03/2012
16
31
Caso de Uso – Descrição expandida
Caso de Uso: Comprar Itens
Atores: Caixa
Descrição: Um cliente chega ao checkout com itens para 
comprar. O caixa registra os itens e recebe o 
pagamento. Ao final, o cliente sai com os itens 
comprados.
Curso Normal
1- caixa passa na leitora de código de barras cada ítem e informa sua
quantidade
2- o sistema verifica que o ítem é válido e apresenta seu valor
3- caixa informa fim dos ítens e solicita fechamento da conta
4- o sistema calcula e apresenta o total
5- caixa recebe o pagamento
6- o sistema emite a nota fiscal
UML
Caso de Uso – Relacionamentos
• Generalização
• Inclusão
• Extensão
32
UML
03/03/2012
17
Caso de Uso – Relacionamento de Extensão
33
V e n d e d o r
C ad a s tra r C l i e n te
R e g is tra r C o n tra to
< < e xte n d > >
UML
Caso de Uso – Relacionamento de Inclusão
34
Efetivar Saque
Caixa Realizar Saque com Cheque
<<inc lude >>
Cliente Realizar Saque com Cartão
<<include>>
UML
03/03/2012
18
Caso de Uso – Relacionamento de Generalização
35
M a tr i c u l a r A l u n o E s tr a n g e i r o
A te n d e n te
M a tr i c u l a r A l u n o
UML
Caso de Uso –Generalização de atores
36
Vender
Equipamento
Autorizar
Crédito
Gerente
Vendedor
O Gerente também pode efetuar vendas
UML
03/03/2012
19
UML – Diagrama de Classe
37
Diagrama de Classe
• Descreve relações estáticas, basicamente:
– Classes e sub-classes
– Relacionamentos
38
UML
03/03/2012
20
Diagrama de Classe – notação
• Classe - atributos + operações ou serviços
• Relacionamento
– Associação
– Generalização
– Agregação – simples ou composição
– Auto-relacionamento
• Classe associativa
• Papel no relacionamento
• Multiplicidade
39
UML
Diagrama de Classe – notação de classe
40
UML
03/03/2012
21
41
Diagrama de Classe – relacionamento de generalização 
- Restrição da cobertura (parcial, sobreposta) 
UML
42
Diagrama de Classe – relacionamento de generalização 
- Restrição da cobertura (parcial, exclusiva) 
UML
03/03/2012
22
43
Diagrama de Classe – relacionamento de generalização 
- Restrição da cobertura (total, exclusiva) 
UML
44
Diagrama de Classe – relacionamento de generalização 
- Restrição da cobertura (total,sobreposta) 
UML
03/03/2012
23
45
Diagrama de Classe – relacionamento de agregação e de composição
UML
46
Diagrama de Classe – classe associativa
UML
03/03/2012
24
47
Diagrama de Classe – auto-relacionamento e papel no relacionamento
UML
48
UML
Diagrama de Classe – exemplo
03/03/2012
25
49
UML
Diagrama de Classe – exemplo
50
UML
Diagrama de Classe – exemplo
03/03/2012
26
UML – Diagrama de Estado
51
Diagrama de Estado - Introdução
• Usado para modelar o comportamento de um objeto do sistema que 
possua comportamento dinâmico
• Importante para entendermos e validarmos o comportamento dos objetos 
durante a suas vidas 
• Normalmente utilizado para representar o comportamento de objetos de 
classes
• Não é necessário construir DE para todas as classes
52
UML
03/03/2012
27
Diagrama de Estado - Notação
53
UML
DE - Elementos
• Estado
• Evento
• Transição
• Ação
• Condição
• Atividade
54
UML
03/03/2012
28
55
Comprador informa novo pedido/ cadastrar Pedido
UML
56
Funcionário informa novo carro/ Cadastrar Carro
UML
03/03/2012
29
57
UML
DE - Avançado
• Um estado pode conter outros estados, concorrentes ou independentes –
Estado Composto
• Transição de e para Estados Compostos
• Transições de e para Estados Concorrentes
58
UML
03/03/2012
30
UML – Diagrama de Atividades
59
Diagrama de Atividades
• Descreve uma sequência de atividades, com suporte para comportamento 
condicional e paralelo
• As transições são disparadas pelo término da atividade
• Serve para modelar um caso de uso com muitos fluxos alternativos 
significativos
• Serve para modelar as atividades de um processo de negócio (modelo de 
workflow)
60
UML
03/03/2012
31
Diagrama de Atividades – condições e intercalações
61
UML
Diagrama de Atividades – separações e junções des
62
UML
03/03/2012
32
Diagrama de Atividades – separações, junções e thread 
condicional
63
UML
Diagrama de Atividades – partição, eventos de entrada e de saída
64
UML
03/03/2012
33
Diagrama de Atividades – eventos em separações
65
UML
UML – Diagrama de Sequência
66
03/03/2012
34
Diagrama de sequencia - introdução
• Diagramas de Sequência apresentam a interação entre um grupo de 
objetos (ou classes) de um sistema, através de mensagens, em um 
determinado Cenário. 
• Diagramas de Sequência são primariamente utilizados para a atribuição de 
responsabilidades a cada um dos objetos do sistema – operações
• Completa o tripé da análise:
– Casos de Uso - comportamento externo (funcional)
– Diagramas de Classes - visão estática
– Diagramas de Sequência - visão dinâmica
• deve ser desenvolvido um Diagrama de Sequência para cada cada cenário 
de um Caso de Uso
67
UML
Diagrama de Colaboração
Janela d e 
Entrada de 
Pedido
um Pedido
uma linha
de
Pedido
um item
em Es toqu e
um I tem de
Entrega
um Item de
Refabrica ção
criar()
* criar()
verif ica ()
[ve rfif ica = true]
retirar_item ()
r efabricar_item ()
[refab ricar_item = tr ue]
new 
[verf ifica = t rue]
new
Diagrama de Atividade
Janela d e 
Entrada de 
Pedido
um Pedido
uma linha
de
Pedido
um item
em Es toqu e
um Item de
Entrega
um Item de
Refabrica ção
criar()
* criar()
verif ica ()
[ve rfif ica = true]
retirar_item ()
r efabricar_item ()
[refab ricar_item = tr ue]
new 
[verf ifica = true]
new
Diagrama de Classes
MeioTranspo rte
Carro N avio
.. .
Caso de Uso
Nome: Reservando Passagem
Atores: Agente
Curso de Eventos
1- Ujfsaj jfklsdj jfdkkj fl als ;a f a;
2- jfaskdjf lj kl;k kdfjasdkl lkssss
3- jsdkfklk lkkkk lopjfa[ pokfsaoopw
4- skdjfI)kkk;’PIO lkkfapp kjadfp 
5- lkLKO oeppae fokkzp;xp pokf ;lp[
Alternativas
 1- Ijfksa kJFKJ a;lkj ;kjfklasojk;a 
Diagrama de Sequência
J anela d e 
Entrada de 
Pedido
um Pedido
uma linha
de
Pedido
um item
em Es toqu e
um I tem de
Entrega
um Item de
Refabrica ção
criar()
* criar()
verif ic a ()
[ve rfif ica = true]
retirar_item ()
r efabric ar_item ()
[ refab ricar_item = tr ue]
new 
[verf ific a = t rue]
new
Objetos Cenário
Interação
68
Diagrama de sequencia – relacionamento com outros 
diagramas
UML
03/03/2012
35
Diagrama de sequencia - notação
• Linha da Vida
• Mensagens
• Informações de Controle
• Auto-delegação
• Condição
• Iteração
69
UML
70
Diagrama de Sequencia
UML
03/03/2012
36
UML – Diagrama de Colaboração
71
Diagrama de Colaboração – introdução
• Diagramas de Colaboração ilustra as interações entre objetos no formato 
de grafo.
• Da mesma forma que os Diagramas de Sequência são utilizados para a 
atribuição de responsabilidades a cada um dos objetos do sistema -
operações
• Possui uma maior economia de espaço em relação ao diagrama de 
sequencia
72
UML
03/03/2012
37
• Diagrama de colaboração
73
UML
Diagrama de componentes
• Mostra a estrutura de componentes
• Representa dependências estáticas
• Compilação entre programas
cliente.execliente.html
index.html
74
UML
03/03/2012
38
75
Diagrama de Implantação
UML
Elementos Genéricos
• Nota: é um comentário inserido no diagrama
• Constraint (restrições): é uma relação semântica entre elementos do 
modelo. Especifica condições ou proposições que devem ser mantidas 
verdadeiras. Uma restrição é mostrada como uma cadeia entre chaves {}. 
(OCL – Object Constraint Language)
76
UML
03/03/2012
39
Elementos Genéricos - Pacotes
•Packages agrupam elementos de modelagem.
•Packages podem conter classes, relacionamentos, classes abstratas, 
Packages, tipos, etc...
77
UML
Elementos Genéricos - Estereótipo
• Mecanismo de extensão introduzido pela UML, que permite 
estender o meta-modelo para suprir necessidades que não 
encontram-se entre os meta-elementos disponíveis, desde 
que a definição semântica da própria linguagem não seja 
ferida.
• Um estereótipo pode ser aplicado a classes, relacionamentos 
de dependência, atributos, operações, etc.
78
UML
03/03/2012
40
Parte 3
Processo de Desenvolvimento de Software 
conceitos básicos – RUP e XP
79
80
• Desenvolver o produto que
atenda as necessidades do
cliente e seja entregue no
prazo, com o custo e o
nível de qualidade
desejado.
O que desejamos em nossos projetos?
Proc.Desev.
Software
03/03/2012
41
Apresentação de Jim Johnson no XP2002 – disponível em www.xp2003.org/xp2002/index.html
A crise do software:
•Apenas 10% dos projetos são concluídos no prazo e orçamento estimados
•O orçamento é ultrapassado em 60% dos projetos 
•25% a 30% dos projetos maiores são cancelados antes da implantação
•Os projetos médio tem um atraso acima de 1 ano e um custo 100% acima do 
orçamento
•Os custos de manutenção representam 80% dos recursos disponíveis
81
O que obtemos em nossos projetos?
Proc.Desev.
Software
Desenvolver Software
Desenvolver software não é somente modelar e escrever código. É criar 
aplicações que resolvam os problemas dos usuários. É fazer isto dentro do 
prazo, de forma precisa e com alta qualidade.
Ambler, 1998
•Melhorar a qualidade do software implica na melhoria do processo pelo qual 
o mesmo é produzido.
•Processos, métodos e ferramentas usados para produzir constituem o escopo 
de estudo da Engenharia de Software.
82
Proc.Desev.
Software
03/03/2012
42
Foco na Qualidade
Processo
Método (Enfoque)
Ferramentas
Engenharia de Software
Estudo e aplicação de procedimentos sistemáticos,
disciplinados e quantificáveis ao desenvolvimento,
operação e manutenção de software.
IEEE/93
83
Proc.Desev.
Software
Principais atividades executadas em um projeto software
• Levantamento de Requisitos – define as características e capacidades que 
o sistema deverá possuir para atingir o seu propósito
• Análise – define o que precisa ser feito
• Projeto – define como deve ser feito de modo a atender critérios de 
qualidade
• Implementação – codificação do software
• Teste 
• Implantação – disponibilização do software nas instalações do usuário, 
treinamento, carga de dados iniciais
84
Proc.Desev.
Software
03/03/2012
43
Critérios de Qualidade para um projeto de software
- Manutenibilidade
- Performance
- Interatividade
- Confiabilidade
- Segurança
- Economia
85
Proc.Desev.
Software
Processo 
Define:
• Quem faz o que e quando
• A aplicação de métodos e ferramentas
• Os produtos que devem ser entregues
• Os controles que ajudam a assegurar a qualidade e a gerenciar as 
mudanças
• Os marcos de referência que permite avaliar o progresso
• Processo = Métodos e Padrões + Pessoas + Ferramentas
86
Proc.Desev.
Software
03/03/2012
44
Agilidade do Processo
• Um processo de software pode ser:
– Preditivo
• Rígido independente do projeto
• Burocrático
– Adaptativo
• Adaptado as necessidades de cada projeto
• Adaptado as características da equipe
• Ágil
• Incorpora o conceito de Framework
87
Proc.Desev.
Software
Levantamento 
de Requisitos
Análise e Design
Implementação
Implantaçã
o
Teste
88
Evolução dos Modelos de Processos - Modelo Cascata
Proc.Desev.
Software
03/03/2012
45
Evolução dos Modelos de Processos - Modelo Cascata
• Características
– Ainda hoje o modelo de processo mais utilizado.
– As atividades são executadas seqüencialmente.
– Uma fase só é iniciada após o final da anterior.
– Pressupõe requisitos estáveis.
– Baseado em modelos de processos de engenharia.
• Modelo Cascata – Prós e Contras
– Vantagens
• É simples de gerenciar.
– Desvantagens
• Difícil lidar com as mudanças.
• Atrasa a redução dos Riscos.
89
Proc.Desev.
Software
Evolução dos Modelos de Processos - Modelo Prototipação
• Construção de protótipos baseado nas informações do cliente
• Adequado para quando o “negócio” não é bem conhecido, o 
cliente não sabe exatamente o que precisa ou como deve ser a 
interface do sistema
• Fases:
Levantamento
Implementação
Avaliação
Projeto Rápido
90
Proc.Desev.
Software
03/03/2012
46
Evolução dos Modelos de Processos - Modelo Prototipação
• Problemas
– O usuário não entende que o software desenvolvido sacrifica qualidade para 
obter velocidade no desenvolvimento e não pode ser considerado como um 
produto que possa entrar em produção. 
– O desenvolvedor muitas vezes toma decisões de projeto, ineficientes, para 
facilitar o desenvolvimento e acaba se acostumando com tais decisões, 
esquecendo o motivo que o levou a tomá-las.
91
Proc.Desev.
Software
Evolução dos Modelos de Processos - Modelo Incremental
• Combinação do modelo cascata com o prototipação
• Adequado para quando a equipe disponível não é suficiente para cumprir o prazo
• Incrementos podem ser planejados para contemplar riscos técnicos
• Para cada incremento entregue é cumprida um seqüência como o cascata
• O primeiro incremento implementa requisitos básicos
• Cada novo incremento acrescenta novas funcionalidades
• Cada incremento tem que ser um produto operacional
92
Proc.Desev.
Software
03/03/2012
47
Evolução dos Modelos de Processos - Modelo Incremental
Levantamento Análise Projeto Implementação
Teste 
e 
Planejamento
Análise Projeto Implementação
Teste 
e 
Planejamento
Análise Projeto ImplementaçãoTeste 
e 
Planejamento
1o
Incremento
2o
Incremento
93
Proc.Desev.
Software
Modelo Iterativo e Incremental
• O que é uma iteração?
– Uma divisão do tempo do projeto, fixa em duração, durante a qual as 
atividades inerentes ao desenvolvimento são executadas. 
• Por que precisamos usar iterações?
– Para ganhar maior controle sobre o projeto e para minimizar os riscos.
94
Proc.Desev.
Software
03/03/2012
48
Características Recomendadas para um processo
• Orientado a objetos
• Guiado por funcionalidades (caso de uso)
• Baseado na arquitetura
• Iterativo e incremental
95
Proc.Desev.
Software
IBM-Rational Unified Process - RUP
96
03/03/2012
49
Método Booch
OMT
Rumbaugh Objectory
(OOSE)
Jacobson
USDP
(UP)
RUP
97
USDP (UP) e RUP
RUP
98
Visão Geral
RUP
03/03/2012
50
Dimensões
• Dimensão horizontal: Representam as fases do desenvolvimento e 
mostra os aspectos do ciclo de vida a medida que o tempo passa. 
Aspectos dinâmicos.
• Dimensão vertical: Representa as disciplinas centrais do processo as 
quais agrupam as atividades de engenharia de software por sua natureza. 
Aspectos estáticos.
99
RUP
Marcos e Pontos de Controle
• Correspondem aos pontos de verificação ao final de cada fase
• Só deve passar para uma próxima fase se os objetivos da fase anterior 
forem alcançados
– LCO (Life Cicle Objective) – no final da Concepção quando o escopo é 
conhecido e bem fundamentado.
– LCA (Life Cicle Architecture) – no final da Elaboração quando a 
arquitetura está completa e o conjunto de requisitos foi definido.
– IOC (Initial Operational Capability) – no final da Construção e marca a 
primeira versão beta.
– PR (Product Release) – no final da Transição e do ciclo de 
desenvolvimento
• Pontos de controle menores são definidos no final de cada iteração.
100
RUP
03/03/2012
51
101
Fases e Marcos
• As fases indicam a maturidade do sistema. Representa o tempo e 
mostra os aspectos do ciclo de vida a medida que este tempo 
passa.
RUP
1- Concepção: Entender o problema e garantir que existe uma 
solução possível e viável.
• Descriminar os casos de uso críticos do sistema
• Apresentar uma arquitetura candidata
• Fazer uma estimativa geral do custo global do projeto
102
RUP
03/03/2012
52
Fases
1- Concepção – possíveis artefatos iniciados na fase
• Documento de visão 
• Modelo de Caso de Uso
• Especificações suplementares
• Glossário
• Plano de Desenvolvimento de Software
• Pasta de Desenvolvimento
103
RUP
2 - Elaboração: Definir a arquitetura e riscos de requisitos
• Compreensão sólida dos casos de uso mais críticos
• Elaborar o processo, a infra-estrutura e o ambiente de 
desenvolvimento
• Elaborar a arquitetura e selecionar os componentes 
104
RUP
03/03/2012
53
2 – Elaboração – possíveis artefatos refinados resultantes da 
fase
– Modelo de caso de uso (pelo menos 80% completo)
– Visão
– Especificações suplementares
– Glossário
– Plano de Desenvolvimento de Software
– Pasta de Desenvolvimento
105
RUP
2 – Elaboração – possíveis artefatos iniciados resultantes da 
fase
• Modelo de domínio
• Modelo de projeto
• Documento da arquitetura do software
• Modelo de dados
• Modelo de implementação
• Modelo de testes
106
RUP
03/03/2012
54
3 - Construção: Identificar os requisitos restantes e concluir a 
implementação.
• Minimizar custos de desenvolvimento
• Produzir um produto pronto na plataforma adequada
107
RUP
3 – Construção – possíveis artefatos refinados resultantes da 
fase
• Modelo de Projeto
• Modelo de Dados
• Modelo de Implementação
• Plano de Desenvolvimento de Software
• Modelo de Teste
108
RUP
03/03/2012
55
4 -Transição: assegurar que o software está disponível para os 
usuários.
• Operação paralela com o sistema legado
• Conversão de banco de dados
• Treinamento dos usuários
109
RUP
4 – Transição – possíveis artefatos refinados resultantes da 
fase
• Modelo de Implementação
• Plano de Desenvolvimento de Software
110
RUP
03/03/2012
56
Disciplinas
• Principais
– Modelagem de Negócio
– Requisitos
– Análise e Projeto
– Implementação
– Teste
– Implantação (Entrega)
111
RUP
Disciplinas
• Suporte
– Gerência de Configuração e de Mudanças
– Gerência de Projeto
– Ambiente
– Planejamento de Projeto
112
RUP
03/03/2012
57
Disciplinas
• Requisitos
– Construir artefatos que descrevem os requisitos do software
– Estabelecer formalmente quais os requisitos funcionais e não 
funcionais que serão atendidos
– Para a definição dos requisitos funcionais utiliza-se Caso de 
Uso
– Artefatos: modelo de caso de uso, especificação 
suplementares, documento de visão
113
RUP
Disciplinas
• Análise e Projeto
– Transformar os requisitos em projeto de sistemas
– Representação visual de todos os elementos necessários para 
implementação de caso de uso
– Artefatos: modelo de projeto, documento de arquitetura de 
software, modelo de dados
– Maior ênfase na fase de Elaboração
114
RUP
03/03/2012
58
Disciplinas
• Implementação
– Implementar em componentes os elementos de projeto
– Testar os componentes como unidades
– Integrar os componentes
– Artefatos: Modelo de Implementação
115
RUP
Disciplinas
• Testes
– Avaliar se todos os requisitos foram implementados 
corretamente
– Avaliar a interação entre os componentes implementados
– Avaliar a integração do software
– Assegurar a correção de defeitos
– Artefato: Modelo de teste
116
RUP
03/03/2012
59
Disciplinas
• Implantação
– Determina a disponibilidade do sistema nas instalações do 
usuário
– Assegurar que o produto está pronto para utilização
• Usuários treinados
• Banco de dados populado
• Documentação técnica finalizada
117
RUP
Disciplinas
• Gerenciamento de Configuração e Mudança
– Controlar as versões de alterações
– Controlar acesso e alterações aos artefatos
• Gerenciamento de Projeto
– Planejamento de Projeto
– Acompanhamento do Projeto
– Artefato: Plano de Desenvolvimento do Software
• Ambiente
– Suportar o ambiente para o projeto – Processo, metodologia, 
ferramentas, estrutura organizacional, infra-estrutura de hardware e 
software
– Artefato: Pasta de Desenvolvimento
118
RUP
03/03/2012
60
Recomendações
• Não se deve planejar todas as iterações de forma detalhada no 
início do projeto
• Não se deve assumir compromissos a longo prazo na fase de 
concepção
• Não se deve selecionar funcionalidades de baixo risco nas 
primeiras iterações
• RUP é um framework não um processo específico. Precisa ser 
ajustado para cada situação. 
119
RUP
Processos Ágeis de Desenvolvimento e Extreme 
Programming (XP)
120
03/03/2012
61
Processos Ágeis – manifesto
www.agilealliance.org:
Estamos descobrindo maneiras melhores de se desenvolver software,
aplicando-as e ajudando os outros a aplicá-las. Deste trabalho nós
valorizamos:
• Indivíduos e interações mais que processos e ferramentas
• Trabalhar no software mais que documentação abrangente
• Colaboração do Cliente mais que negociação contratual
• Responder às mudanças mais que seguir um plano
É isto, embora exista valor nos itens da direita, nós valorizamos mais os itens da 
esquerda.
121
XP
Características dos processos Ágeis
• Adaptabilidade X Previsibilidade 
– A Engenharia de Software e as demais Engenharias;
– A diferença entre as fases de Projeto e Construção;
– Negócios Atuais: Mudança constante de requisitos;
– Adaptabilidade exige um ciclo iterativo;
– Adaptabilidadeexige participação extrema do cliente;
122
XP
03/03/2012
62
Processos Ágeis - Valores
• Simplicidade
• Comunicação
• Feedback
• Coragem
123
XP
Origem
• Chrysler Comprehensive Compensation system (C3)
• Novo sistema de folha de pagamento, unificando os sistemas 
existentes
• Projeto Orientado a Objetos usando Smalltalk
• De 1995 a 1996 – Empresa contratada inicia o projeto. Os 
resultados obtidos são ruins e o projeto entra em crise.
• Kent Beck avalia o projeto e constata seu estado crítico.
• De 1997 a 1999 – Liderado por Beck, o projeto se tornou o 
laboratório das práticas que hoje formam o XP
XP
03/03/2012
63
A Premissa Extrema
XP
• Jogo do Planejamento
• Pequenas Versões
• Projeto Simples
• Refatoração
• Teste Primeiro
• Programação em Pares
• Metáfora
• Padrões de Codificação
• Propriedade Coletiva do 
Código
• Integração Contínua
• Semana de 40 horas
• Testes de Aceitação
• Cliente “on-site”
126
XP - Práticas
XP
03/03/2012
64
Exploration Planning Iterations to Release Productionizing
127
XP - O Ciclo de Vida de um Projeto
XP
128
XP - A Força do Conjunto
XP
03/03/2012
65
• Modelo Tradicional:
– Tempo
– Custo
– Escopo
– Manipula-se a 
Qualidade
� Modelo XP:
� Tempo
� Custo
� Qualidade
� Manipula-se o Escopo
Contratos de Preço 
Pré-Fixado
Contratos de 
Escopo Varável
129
XP - Variáveis de Projeto
XP
Prioridade: 1
Renovação de Matrícula
As disciplinas disponíveis para matrícula devem ser 
apresentadas. O aluno escolhe as disciplinas
desejadas e confirma. Um e-mail com a confirmação
da matrícula é enviado para o aluno.
3 Dias
Equipe estima a estória em Tempo Ideal
Cliente prioriza.
Conte-me uma Estória
XP
03/03/2012
66
Release Planning
• Cliente escreve as estórias.
• Equipe de desenvolvimento
estima as estórias.
• Estórias muito pequenas são
unificadas, estórias muito grande
são quebradas.
• Cliente prioriza as estórias.
• Equipe ajuda o cliente a entender
riscos técnicos.
• Cliente define os releases.
XP
Iteration Planning
• Cliente define estórias que devem ser implementadas na iteração
considerando a velocidade definida pela equipe.
• Cliente e equipe conversam sobre as estórias selecionadas.
• Desenvolvedores se oferecem para implementar determinadas tarefas.
• Equipe identifica as tarefas de programação necessárias para implementar
as estórias da iteração.
• Equipe estima e prioriza as tarefas.
XP
03/03/2012
67
• Cada dia de trabalho
“começa” com uma reunião, 
onde todos conversam sobre
os problemas encontrados no 
dia anterior e definem as 
prioridades do dia que se 
inicia.
• A reunião é curta, mais ou
menos uns 15 minutos. O fato
de ser em pé ajuda a alcançar
este objetivo.
Web Designer ?
Stand Up Meeting
XP
• A primeira coisa que deve ser 
feita para se começar um 
projeto XP é reorganizar o 
ambiente.
• White Boards.
• Mobília preparada para o 
trabalho em duplas.
• Mural para colocar os cartões.
Ambiente de Trabalho
XP
03/03/2012
68
• Desenvolver um sistema para Acompanha-mento da Vida Acadêmica de 
alunos da XP University.
• Condições do Cliente:
– Criar um sistema para uso na Web com acesso pelo site da 
universidade.
– Precisa entrar no ar no início de Junho/2009
Exemplo
XP
• Levantamento das Estórias
Estória Dificuldade
(em dias ideais)
Atualizar Dados Pessoais do Aluno 3
Consultar Quadro de Horários 4
Listar Turmas Inscritas 3
Verificar Recursos Disponíveis da Turma 3
Donwload de Recurso 2
Renovação de Disciplina 12
Inclusão/Exclusão de Disciplina 6
Total de Dificuldade = 33
XP
03/03/2012
69
• Refinamento das Estórias:
– Maiores do que uma iteração
– Divisão do Conceito
Estória Dificuldade
(em dias ideais)
Prioridade
Atualizar Dados Pessoais do Aluno 3 1
Consultar Quadro de Horários 4 1
Listar Turmas Inscritas 3 1
Verificar Recursos D isponíveis da Turma 3 1
Donwload de Recurso 2 1
Apresentar D isciplinas Oferecidas 7 2
Simular Quadro de Horários 5 2
Inclusão de Disciplina 3 3
Exclusão de Disciplina 3 3
Total de Dificuldade = 33 (Poderia Mudar)
XP
Release Planning
• Tamanho da Iteração = 2 semanas reais (10 Dias)
• Total de Dificuldades = 33 dias ideais
• Velocidade Inicial:
• 1 desenvolvedor - 5 DI em uma iteração
• 2 desenvolvedores - 10 DI em uma iteração
• Total de Iterações necessárias = 3.3 ou seja 4.
• Considerar dois Releases de 1 mês cada (2 iterações)
– Entregar uma versão no início de fevereiro.
– Cliente define o escopo.
XP
03/03/2012
70
• Release Planning - Release 1
 i1 – 01/04 – 12/04 
 
Atualizar Dados Pessoais do Aluno 3 
Consultar Quadro de Horários 4 
Listar Turmas Inscritas 3 
 
 i2 – 15/04 – 26/04 
 
Verificar Recursos Disponíveis da Turma 3 
Apresentar Disciplinas Oferecidas 7 
 
XP
Release Planning - Release 2
– Planejar somente 1 ou 2 releases. Não prever o futuro.
– Só definir o limite de datas:
• i3 – 29/04 – 10/05
• i4 – 13/05 – 24/05 OU
Exemplo - Cont.
 i3 – 29/04 – 10/05 
 
Donwload de Recurso 2 
Simular Quadro de Horários 5 
Inclusão de Disciplina 3 
 
 i4 – 13/05 – 24/05 
 
Exclusão de Disciplina 3 
 
XP
03/03/2012
71
• Dividindo a Estória em Tarefas:
Estória: Atualizar Dados Pessoais do Aluno 3
Tarefas
Criar Página ASP 1.5
Desenvolver Componente COM 2
Criar Tabelas no Banco de Dados 0.5
Estimativa Total: 4
XP
• Ao final de cada iteração: medir o Andamento do Projeto. 
• Decisões:
– Novas Estórias;
– Retirar Estórias;
– Mudança de Prioridade;
– Ajuste nas Estimativas;
– Too Much To Do;
– Too Little To Do;
XP