Sei sulla pagina 1di 179

Engenharia Fowler / Booch /

Jacobson /
de Software Rumbaugh /
Guedes /
Cordeiro
Anlise e
Projetos de
Sistemas OO -
II
Teoria e
Exerccios

gabrielpacheco@euvoupassar.com.br

www.tiparaconcursos.net facebook.com/tiparaconcursos twitter.com/gabrielfpacheco


1
2
3
4
Contedo Programtico.

Anlise e projeto de sistemas:


Anlise e projeto estruturado / Anlise
estruturada.
Anlise e projeto OO.
Conceitos fundamentais.
Anlise.
Modelagem.
Padres de projeto.
UML.

5
Anlise e projeto de Sistemas
Estruturado X OO
Estruturado:
Foco no como fazer.
Inadequao entre o comportamento e a estrutura de
dados.
Sensvel a mudanas.
Sem noo de estrutura e responsabilidade.
Impossibilidade de medirmos o impacto de uma mudana.

6
Anlise e projeto de Sistemas
Estruturado X OO
OO:
Foco no que fazer.
Estrutura de dados e comportamento em mesmo modelo.
Estrutura de responsabilidade definida.
Pode-se medir o impacto de uma mudana.

7
Anlise e projeto de Sistemas
Modelos OO
Procedimentos de concepo de sistemas a partir
dos conceitos de OO.
Corresponde s principais fases de um ciclo de vida
de software genrico.
Especificao de software.
Projeto e implementao de software.
Validao de software.
Evoluo de software.

8
Anlise e projeto de Sistemas
Modelos OO
OMT Object Modelling Tecnique:
4 fases: anlise, projeto de sistema, projeto de objetos e
implementao.
Fase de anlise com 3 diagramas que representam os
modelos de objeto, dinmico e funcional.
Booch:
Baseado em 3 fases: anlise de requisitos, anlise de
domnios e projetos.
Trabalhando com os diagramas: de classes, de transio de
estados, de objetos, temporais, de mdulos e de
processos.

9
Anlise e projeto de Sistemas
Modelos OO
Coad/Yourdon: utiliza um modelo nico para OOA,
OOD e OOP.
Shlaer/Mellor: conjunto integrado de modelos de
anlise e que depois so traduzidos durante o
projeto.
OOSE (Jacobson): centrado em UCs com
aprofundamento no andar da carroagem.
Fuso (OMT e Jacobson): integrao entra OMT e
Booch.
UML: Unificao do OMT, Booch e OOSE.

10
Anlise e projeto de Sistemas
POO Modelagem Orientada a Objeto
Abstrao com propsito de entender um problema
antes de solucion-lo.
Possibilita a simulao e testes de um sistema antes
mesmo dele ser construdo.
Facilita a comunicao entre usurios e membros da
equipe de desenvolvimento.

11
Anlise e projeto de Sistemas
POO Modelagem Orientada a Objeto
OMT:
Modelo Objeto: aspectos estticos, estruturais, dados do
sistema.
Modelo Dinmico: aspectos temporais, comportamentais,
controle do sistema.
Modelo Funcional: representa os aspectos
transformacionais e de funo de um sistema.
Todos eles esto interconectados, depende do nvel de
abstrao que est sendo utilizado.

12
Anlise e projeto de Sistemas
POO Anlise e Projeto OO
Abordagem RUP X UML.
Anlise Orientada a Objetos: desenvolvimento de um
modelo orientado a objetos do domnio da aplicao.
Devem refletir as entidades e as operaes associadas ao
problema a ser resolvido.
Projeto Orientado a Objetos: desenvolvimento de um
modelo orientado a objetos de um sistema. Os objetos
devero estar relacionados soluo do problema.
Programao Orientada a Objeto: realizar um projeto de
software usando uma linguagem de programao
orientada a objetos.
A transio entres estes estgios deve ser contnua com
notaes compatveis a cada estgio.
13
Anlise e projeto de Sistemas
Rational Unified Process - RUP
Descrito a partir de trs perspectivas:
Dinmica fases do modelo ao longo do tempo.
Esttica atividades realizadas no processo.
Prtica boas prticas a serem usadas durante o
processo.

14
Anlise e projeto de Sistemas
Rational Unified Process - RUP

15
Anlise e projeto de Sistemas
Rational Unified Process - RUP
Modelo constitudo por 4 fases discretas:
Concepo: estabelecer um business case para o
sistema. Avaliao do ambiente de negcio em
relao contribuio de um sistema para o
negcio. (escopo)
Elaborao: desenvolver um entendimento do
domnio do problema, estabelecer um framework,
desenvolver um plano de projeto e identificar os
riscos principais do projeto. (modelo de requisitos
para o sistema).(arquitetura).

16
Anlise e projeto de Sistemas
Rational Unified Process - RUP
Modelo constitudo por 4 fases discretas:
Construo: relacionada ao projeto, programao e
teste de sistema. As partes so desenvolvidas
separadamente e integradas. Software funcional +
documentao. (desenvolvimento)
Transio: fase final do RUP. Transferncia do
desenvolvimento para o usurio. Entrada do sistema
em produo. Fase onerosa e problemtica.
(implantao).

17
Anlise e projeto de Sistemas
Rational Unified Process - RUP

Cada fase pode ser realizada de forma iterativa, com


resultados desenvolvidos incrementalmente.
O conjunto total de fases pode ser realizada de forma
incremental.

18
Anlise e projeto de Sistemas
Rational Unified Process - RUP
Viso esttica do RUP (os Workflows):
Fases so dinmicas e tem objetivos.
Workflows so estticos e constituem atividades tcnicas
que no esto associadas a uma nica fase.
As fases no esto associadas aos workflows especficos.

19
Anlise e projeto de Sistemas
Rational Unified Process - RUP
Viso esttica do RUP (os Workflows):
Modelagem de negcios: processos de negcio so
modelados usando casos de uso de negcios.
Requisitos: agentes que interagem com o sistemas so
identificados e os UCs so desenvolvidos para modelar os
requisitos de sistema.
Anlise e projeto: modelo de projeto criado e
documentado usando modelos de arquitetura, modelos de
componente, modelos de objeto e modelos de sequencia.
Implementao: componentes de sistema so
implementados e estruturados em subsistemas de
implementao.

20
Anlise e projeto de Sistemas
Rational Unified Process - RUP
Viso esttica do RUP (os Workflows):
Teste: processo iterativo realizado em conjunto com a
implementao.
Implantao: verso do produto criada, distribuda aos
usurios e instalada.
Gerenciamento de configurao e mudanas: gerencia as
mudanas do sistema.
Gerenciamento de projetos: gerencia o desenvolvimento
do sistema.
Ambiente: est relacionado disponibilizao de
ferramentas apropriadas de software para a equipe de
desenvolvimento.

21
Anlise e projeto de Sistemas
Rational Unified Process - RUP
O RUP recomenda 6 melhores prticas fundamentais
(linhas mestras):
Desenvolver o software iterativamente: incrementos de
software priorizados e entregues.
Gerenciar requisitos: documentao e acompanhamento
das mudanas dos requisitos.
Usar arquiteturas baseadas em componentes: estruturar a
arquitetura de sistema de componentes.
Modelar o software visualmente: modelos grficos UML.
Verificar a qualidade do software: atendam aos padres de
qualidade da organizao.
Controlar as mudanas do software: usando um SGM e
procedimentos. 22
Anlise e projeto de Sistemas
RUP Desenvolvimento Iterativo
Ciclo de vida que consiste em vrias iteraes.
Cada iterao incorpora um conjunto quase
sequncial de atividades em modelagem de
negcios, requisitos, anlise de projeto,
implementao, teste e implantao.

23
Anlise e projeto de Sistemas
RUP Desenvolvimento Iterativo

24
Anlise e projeto de Sistemas
RUP Desenvolvimento Iterativo
Riscos detectados e tratados mais cedo, pois os
elementos so integrados progressivamente.
A melhora o refinamento do produto.
Melhoria de seus processos.
Aumento da capacidade de reutilizao.

25
Anlise e projeto de Sistemas
RUP Gerenciamento de Requisitos
Requisito:
Uma condio ou capacidade com a qual o sistema dever
estar em conformidade.
Descries dos servios fornecidos pelo sistema e as suas
restries operacionais.
Reflete as necessidades dos clientes de um sistema que
ajuda a resolver algum problema.

26
Anlise e projeto de Sistemas
RUP Gerenciamento de Requisitos
Gerenciamento de Requisitos:
Abordagem sistemtica para localizar, documentar,
organizar e controlar os requisitos de um sistema.
As chaves para o gerenciamento eficaz de requisitos
incluem manter uma sentena clara dos requisitos, junto
com os atributos aplicveis e a rastreabilidade para outros
requisitos e outros artefatos do projeto.

27
Anlise e projeto de Sistemas
RUP Gerenciamento de Requisitos
Dificuldades na coleta de Requisitos:
Nem sempre os requisitos so bvios e podem vir de vrias fontes.
Existem diversos tipos de requisitos em diferentes nveis de detalhe.
O nmero de requisitos pode se tornar impossvel de gerenciar se eles no
forem controlados.
Os requisitos esto relacionados uns com os outros, e tambm com o
produto liberado do processo de engenharia do software.
Os requisitos tm propriedades exclusivas ou valores de propriedade. Por
exemplo, eles no so necessariamente igualmente importantes ou
igualmente fceis de se atender.
H vrias partes interessadas, o que significa que os requisitos precisam ser
gerenciados por grupos de pessoas de diferentes funes.
Os requisitos so alterados.

28
Anlise e projeto de Sistemas
RUP Uso da Arquitetura de Componentes
Componentes:
Grupos de cdigo coesos, na forma de cdigo fonte ou
executvel, com interfaces bem definidas e comportamentos
que fornecem forte encapsulamento do contedo e so,
portanto, substituveis.
Pedao no-trivial de software, um mdulo, um pacote ou um
subsistema, sendo que todos desempenham uma funo clara,
possuem uma fronteira clara e podem ser integrados em uma
arquitetura bem definida.
Realizao de uma abstrao de design.
As arquiteturas baseadas em componentes tendem a
reduzir o tamanho efetivo e a complexidade da soluo.
29
Anlise e projeto de Sistemas
RUP Modelagem Visual
Uso de notaes de design grficas e textuais para
capturar designs de software.
Uma notao, permite que o nvel de abstrao seja
aumentado, enquanto mantm sintaxe e semntica
rgidas (UML).
Dessa maneira, a comunicao na equipe de design
melhora, medida que o design formado e revisado,
permitindo ao leitor raciocinar sobre ele e fornecendo
uma base no ambgua para a implementao.

30
Anlise e projeto de Sistemas
RUP Modelagem Visual
Capturar a estrutura e o comportamento.
Exibir como os elementos do sistema se integram.
Manter projeto e implementao consistentes.
Esconder ou exibir detalhes como for apropriado.
Proporcionar uma comunicao no ambgua.

31
Anlise e projeto de Sistemas
RUP Contnua Verificao da Qualidade
Caracterstica de ter demonstrado a realizao da
criao de um produto que atende ou excede os
requisitos acordados, conforme avaliado por medidas
e critrios acordados, e que criado em um processo
acordado.
No se trata de uma nica dimenso, mas de vrias e
para tal deve ter seus requisitos definidos.
A localizao e soluo de problemas ficam at 1000
vezes mais caras se realizadas aps a implantao.
A verificao no decorrer do projeto essencial.

32
Anlise e projeto de Sistemas
RUP Contnua Verificao da Qualidade
Identificao das medidas e dos critrios para
demonstrar a obteno da qualidade e a
implementao de um processo para garantir que o
produto criado tenha atingido o grau desejado de
qualidade e possa ser repetido e gerenciado.

33
Anlise e projeto de Sistemas
RUP Gerenciamento de Mudana
Recurso utilizado para superar a dificuldade de
controle no processo de desenvolvimento quando se
fala em mudanas.

34
Anlise e projeto de Sistemas
RUP Princpios Chave
Adaptar Processos.
Balancear Prioridades dos Interessados.
Colaborao entre Times.
Demonstrar Valor da Iteratividade.
Elevar o Nvel de Abstrao.
Foco contnuo na Qualidade.

35
Anlise e projeto de Sistemas
RUP Adaptar Processo
Ciclo de vida eficiente.
Incremento da agilidade do projeto.
Uso de planos e estimativas realsticas.

36
Anlise e projeto de Sistemas
RUP Balancear Prioridade dos Interessados
Alinhamento dos aplicativos s necessidades do
negcio e dos usurios.
Reduo do desenvolvimento customizado.
Otimizao do valor do negcio.

37
Anlise e projeto de Sistemas
RUP Colaborao entre Times
Incremento da produtividade do Time.
Alinhamento entre as necessidades do negcio e o
desenvolvimento e operao dos Sistemas de
Informao.

38
Anlise e projeto de Sistemas
RUP Demonstrar Valor de Iteratividade
Reduo prematura de risco.
Prognostico ao longo do projeto.
Concordncia entre interessados.

39
Anlise e projeto de Sistemas
RUP Elevar o nvel de Abstrao
Maior produtividade.
Reduo d nvel de complexidade.

40
Anlise e projeto de Sistemas
RUP Fco na Qualidade
Alta qualidade.
Incremento do progresso e da qualidade
prematuramente.

41
Anlise e projeto de Sistemas
RUP Viso de processo de software
Processo de software um conjunto de atividades
cujo objetivo o desenvolvimento ou a evoluo de
software. (Sommervile)
Orienta as atividades da equipe.
Especifica as regras para produo dos artefatos.
Direciona as tarefas a serem realizadas pela equipe.
Fornece critrios de medio para os produtos e atividades
do projeto.

42
Anlise e projeto de Sistemas
RUP Viso de processo de software
Rational Unified Processo, or RUP, is a software
engineering process framework developed and
marketed by Rational Software. It comprises many
software development best practices, harvested by
many contributors, over many years of experience, in
a wide variety of situations. (Kroll, Kruchten)
Tem como objetivo garantir a produo de software de
alta qualidade que atenda s necessidades dos
usurios dentro de um cronograma e de um
oramento previsveis.

43
Anlise e projeto de Sistemas
RUP Viso de processo de software

44
Anlise e projeto de Sistemas
RUP Viso de processo de software

45
Anlise e projeto de Sistemas
RUP Viso de processo de software
O RUP possui 2 estruturas ou duas dimenses:
Dimenso vertical: representa a estrutura esttica do
processo. Representa como os elementos do processo
(atividades, disciplinas, artefatos e regras) so logicamente
agrupados dentro do processo ou do workflow.
Dimenso horizontal:
Representa a estrutura dinmica ou dimenso temporal do processo
(ciclos, fases, iteraes e marcos). Mostra como o processo seguir
no ciclo de vida do projeto.
Representa o ciclo de vida do projeto.
Inception, Elaboration, Construction, e Transition.

46
Anlise e projeto de Sistemas
RUP Viso de processo de software
Dimenso vertical: como os elementos de um
processo sero logicamente agrupados (atividades,
disciplinas, artefatos e regras).
Processo = quem, o qu, como e quando.
Quatro elementos chave para modelagem no RUP:
Papel (Regras) = quem.
Tarefas = como.
Artefatos = o qu.
Workflows = quando.

47
Anlise e projeto de Sistemas
RUP Viso de processo de software
Papel:
como um chapu que um indivduo ou grupo usa durante
um projeto.
Lembrem-se que podemos ter vrios chapus.
No RUP o papel representa o que o indivduo ou equipe
deveria realizar definindo a sua competncia e
responsabilidade.

48
Anlise e projeto de Sistemas
RUP Viso de processo de software
Tarefa:
As tarefas de um papel uma unidade de trabalho que um
indivduo pode executar.
Possui um propsito claro, comumente expressado em
termos de criao ou atualizao de algum artefato como
um componente, um modelo ou um plano.
Cada tarefa delegada a um papel especfico.
utilizada como um elemento de planejamento e progresso
do projeto.
Podem ser repetidas algumas vezes, principalmente entre
um iterao e outra.

49
Anlise e projeto de Sistemas
RUP Viso de processo de software
Passos:
So as partes de uma tarefa.
So mais granulares que tarefas.
Dividem-se em trs categorias:
Thinking: entendimento da natureza da tarefa, anlise dos artefatos
de entrada e formulao das sadas.
Performing: regras criando ou atualizando algum artefato.
Reviewing: regras inspecionando o resultado obtido de acordo com
algum critrio.

50
Anlise e projeto de Sistemas
RUP Viso de processo de software
Artefatos:
Um pedao de informao que produzido, modificado ou
usado por um processo.
So elementos tangveis de um projeto.
Coisas que o projeto produz ou usa enquanto trabalha para
alcanar o produto final.
So entradas para executar uma atividade e o resultado ou
sada de outras atividades.
Modelo de caso de uso, um caso de uso, um documento de
viso, um cdigo ou um prottipo.

51
Anlise e projeto de Sistemas
RUP Viso de processo de software
Workflow:
Uma lista de papis, atividades e artefatos no podem
constituir um processo, necessrio o caminho a ser
seguido.
Um Workflow tido como uma descrio de sequencia de
atividades que produzem algum resultado valoroso e mostra
as interaes entre os papis.
Na UML um Workflow poder ser mostrado como um
diagrama de seqncia, um diagrama de colaborao ou um
diagrama de atividades.

52
Anlise e projeto de Sistemas
RUP Viso de processo de software
Um papel expressa quem est fazendo o trabalho;
uma tarefa descreve como o trabalho feito; um
artefato captura o que foi feito.

53
Anlise e projeto de Sistemas
RUP Viso de processo de software
Disciplina:
um container lgico que armazena papis, atividades,
artefatos associados a conceitos, guidelines, e templates.
So nove disciplinas

54
Anlise e projeto de Sistemas
RUP Viso de processo de software

55
Anlise e projeto de Sistemas
RUP Viso de processo de software
Adicionando templates, tool mentors e guidelines ns
teremos os templates iniciando a produo de um
artefato, tool mentors provendo direcionamentos
detalhados para a realizao de uma atividades, ou
passos, usando as ferramentas, e os guidelines
provendo detalhes de direcionamento de atividades,
passos, ou artefatos.

56
Anlise e projeto de Sistemas
RUP Viso de processo de software

57
Anlise e projeto de Sistemas
RUP Viso de processo de software
Processo customizado.
Necessidade gerada pela heterogeneidade das organizaes.
Melhores prticas.

58
Anlise e projeto de Sistemas
RUP Viso de processo de software
Processo customizado (cont).
O RUP consiste de um conjunto de melhores prticas,
ferramentas de configurao para selecionar as praticas
apropriadas, ferramentas de processos de entrega para
acessar as melhores prticas, uma comunidade online para
compartilhar artefatos e experincias, e uma ferramenta de
criao para adicionar suas prprias melhores prticas do
RUP.

59
Anlise e projeto de Sistemas
RUP Viso de processo de software
Dimenso horizontal:
Divide o processo em uma perspectiva gerencial.
Um ciclo de 4 fases que termina com uma release de um
software completo.
Trata-se de forma fundamental a aplicao de iteratividade e
gesto de riscos.
A fase define o estado do projeto onde os estados so
definidos por riscos particulares que voc deve mitigar.

60
Anlise e projeto de Sistemas
RUP Viso de processo de software
Dimenso horizontal (cont):
Iniciao:
Objetivos: entender o escopo do projeto, construir o caso de
negcio, obter os stakeholders envolvidos.
Mitigao dos riscos de negcio.
Entendimento em alto-nvel do que o sistema dever fazer.
Marco: Lifecycle Objetive Milestone (LCO).
Elaborao:
Objetivos: Mitigar os riscos tcnicos, criar linha de base de
arquitetura e entender o que dever ser feito no sistema.
Mitigao dos riscos tcnicos e gesto de riscos de arquitetura.
Reviso do escopo com os requisitos estiverem melhor entendidos.
Marco: Lifecycle Architeture Milestone (LCA).

61
Anlise e projeto de Sistemas
RUP Viso de processo de software
Dimenso horizontal (cont):
Construo:
Objetivo: Desenvolver a primeira verso operacional do produto.
Preocupao com riscos logsticos de execuo.
onde temos o maior nvel de apoio e esforo da equipe.
Marco: Initial Operational Cabability Milestone (IOC).
Transio:
Objetivo: Desenvolver a verso final do produto e entreg-la ao
clientes.
Gesto de riscos associados com a logstica de desenvolvimento para
uso.
Marco: Product Release Milestone (PR).

62
Anlise e projeto de Sistemas
RUP Viso de processo de software
Iniciao - Inception
Primeira fase das quatro fases do ciclo de vida do RUP.
Trata sobre como entender o escopo do projeto e seus
objetivos recolhendo informaes para confirmar
como proceder ou talvez convenc-lo que no deveria.
Objetivos:
Todos os objetivos sero tratados em paralelo.
Entender o que desenvolver: determina a viso, o escopo do
sistema e suas fronteiras, o que est no sistema o que no
est. Identifica quem deseja o sistema e o que requerido.
Identificar as funcionalidades chave: decide quais casos de
uso so mais crticos.

63
Anlise e projeto de Sistemas
RUP Viso de processo de software
Iniciao - Inception
Objetivos (cont):
Determinar o mnimo de possveis solues: identificar no
mnimo uma arquitetura candidata.
Entender o custo, cronograma, e riscos associados com o
projeto.
Decidir qual processo seguir e quais ferramentas usar.

64
Anlise e projeto de Sistemas
RUP Viso de processo de software
Iniciao - Inception
Como caracterstica marcante, temos que a maioria
dos projetos precisam de uma iterao apenas na
iniciao, mas outros precisam de mais para que seja
assim fechado o objetivo do projeto.
Seu marco final a definio dos Objetivos do Ciclo de
Vida. Anlise dos objetivos do ciclo de vida do projeto
e deciso sobre prosseguir ou no com o projeto.

65
Anlise e projeto de Sistemas
RUP Viso de processo de software
Iniciao - Inception
Artefatos:
Documento de Viso: viso que os envolvidos tm do produto a ser
desenvolvido, em termos das necessidades e caractersticas mais
importantes. Em projetos menores pode ser um documento informal.
Caso de Negcio: informaes necessrias do ponto de vista do negcio,
para determinar se vale ou no a pena investir no projeto (ROI).
Plano de Desenvolvimento de Software: informaes necessrias ao
gerenciamento do projeto.
Modelo de Casos de Uso: modelo das funes pretendidas do sistema e
seu ambiente, e serve como um contrato estabelecido entre o cliente e
os desenvolvedores.
Glossrio: termos importantes.

66
Anlise e projeto de Sistemas
RUP Viso de processo de software
Elaborao - Elaboration
Segunda fase do RUP.
Tem por objetivo definir a linha de base da arquitetura
do sistema para prover um caminho feliz na fase de
construo.
Deve considerar os requisitos mais significantes e seus
riscos.

67
Anlise e projeto de Sistemas
RUP Viso de processo de software
Elaborao - Elaboration
O seu objetivo geral traduz-se em quatro objetivos,
sendo cada um orientado por uma rea de risco:
Riscos associados com requisitos (aplicao correta).
Riscos associados com arquitetura (soluo correta).
Riscos associados com custos e cronograma (cominho
correto).
Riscos associados com processos e ferramentas (voc est
com o processo e a ferramenta correta para o trabalho).
Elaborao X Iteraes.

68
Anlise e projeto de Sistemas
RUP Viso de processo de software
Elaborao - Elaboration
Objetivos:
Obter maiores detalhes e entendimento dos requisitos (no
documento de viso ns temos 20% ou os UCs essenciais).
Projetar/desenhar, implementar, validar e criar a linha de
base de arquitetura (arquitetura executvel construda como
um prottipo evolucionrio).
Arquitetura: definindo subsistemas, componentes chaves e
interfaces.
Utilizao de casos de uso para direcionar a arquitetura.
Desenhar/realizar os Casos de Uso. (viso preliminar dos objetos
envolvidos, distribuio do comportamento das classes, detalhar a
analise das classes, desenhar as classes, refinar a analise das classes
dentro do desenho das classes).

69
70
Anlise e projeto de Sistemas
RUP Viso de processo de software
Elaborao - Elaboration
Objetivos (cont):
Consolidar e empacotar as classes identificadas.
Assegurar a cobertura da arquitetura.
Desenhar/projetar a base de dados.
Descrever a arquitetura em termos de concorrncia, processos,
threads, e distribuio fsica.
Identificar os mecanismos arquiteturais (persistncia, comunicao,
autenticao).
Implementar cenrios crticos.
Integrar componentes.
Mitigar os riscos essenciais, produzir um cronograma exato e um
custo estimado.

71
Anlise e projeto de Sistemas
RUP Viso de processo de software
Elaborao - Elaboration
Objetivos (cont):
Refinar o desenvolvimento dos casos de uso.
Revisar o projeto: arquitetura do ciclo de vida.
Marco: arquitetura do ciclo de vida.

72
Anlise e projeto de Sistemas
RUP Viso de processo de software
Elaborao - Elaboration
Artefatos:
Prottipos: usados para reduzir o risco.
Lista de Riscos: associada a aes especficas de contingncia ou
diminuio de riscos.
Documento de Arquitetura de Software: arquitetura abrangente do
sistema, usando diversas vises de arquitetura para descrever diferentes
aspectos do sistema.
Modelo de Projeto: descreve a realizao dos casos de uso e serve
como uma abstrao do modelo de implementao e seu cdigo-fonte.
Modelo de Dados: subconjunto do modelo de implementao que
descreve a representao lgica e fsica dos dados persistentes no
sistema.

73
Anlise e projeto de Sistemas
RUP Viso de processo de software
Construo - Construction
Terceira fase do RUP.
Foco na construo de cdigo de alto-nvel.
Melhoria do foco do desenvolvimento em relao a qualidade,
escopo, tempo e caractersticas aperfeioadas.
Objetivos:
Minimizar o custo de desenvolvimento otimizando recursos e
minimizando o desperdcio.
Desenvolver iterativamente e completar o produto, deix-lo pronto para
a transio.
Revisar o projeto: capacidade operacional inicial.
Marco: capacidade operacional inicial.

74
Anlise e projeto de Sistemas
RUP Viso de processo de software
Transio - Transition
Quarta faz do RUP.
Considera que a construo foi finalizada com uma verso
beta completa do sistema incluindo instalador,
documentao de suporte e material de treinamento, mas
sabe-se que esta verso no a verso final.
A transio ir ajustar em iteraes incluindo testes do
produto para uma release e fazer ajustes baseados em
feedbacks.
Objetivos:
Testar a verso beta e valid-la com o usurio.
Treinar o usurio e manter.
Preparar o local de deploy e converter as bases de dados operacionais.
75
Anlise e projeto de Sistemas
RUP Viso de processo de software
Transio - Transition
Objetivos (cont):
Preparar para o lanamento (pacote, produo e esquemas
de marketing).
Providenciar para os futuros projetos as lies aprendidas.
No final da fase de transio os objetivos devero ter
sido atendidos e o projeto pronto para o fechamento.
O fim deste ciclo poder ser o inicio de um novo ciclo
de vida do mesmo produto. (nova verso)
Marco: release do produto.

76
Anlise e projeto de Sistemas
RUP Viso de processo de software
Transio - Transition
Artefatos:
Notas de Release: identificam mudanas e erros conhecidos
em uma verso ou em uma unidade de implantao que
tenha sido disponibilizada para uso.
Artefatos de Instalao: software e as instrues
documentadas necessrias para instalar o produto.
Materiais de Treinamento: material usado nos programas
ou cursos de treinamento para ajudar os usurios finais com
a utilizao, a operao e manuteno dos produtos.

77
Anlise e projeto de Sistemas
RUP Viso de processo de software

78
Anlise e projeto de Sistemas
RUP Viso de processo de software

79
Exerccios
1. (Infraero Engenharia de Software 2011 - FCC)
41 So duas disciplinas do RUP:

a) Implementation e Inception.
b) Elaboration e Requirements.
c) Deployment e Transition.
d) Requirements e Implementation.
e) Implementation e Construction.

80
Exerccios
2. (Infraero Engenharia de Software 2011 - FCC)
42 No RUP, Stakeholder concurrence on scope
definition and cost/schedule estimates trata de um
critrio de avaliao da

a) Transition phase.
b) Elaboration phase.
c) Configuration discipline.
d) Inception phase.
e) Environment discipline.

81
Exerccios
3. (Infraero Arquitetura de Software 2011 -
FCC) 52 Considere as seguintes fases do RUP:
(F1) Inception, (F2) Elaboration, (F3)
Construction e (F4) Transition e os critrios de
avaliao:
I. Arquitetura estvel.
II. Concordncia dos envolvidos quanto definio do escopo,
estimativas de custo e cronograma.
III. Despesas reais dos recursos versus despesas previstas aceitveis.

A correta associao entre os critrios e as fases


a) I-F1, II-F2 e III-F3.
b) I-F2, II-F3 e III-F4.
c) I-F1, II-F3 e III-F4.
d) I-F2, II-F1 e III-F2.
e) I-F2, II-F3 e III-F1.
82
Exerccios
4. (Infraero Arquitetura de Sistemas Gesto de
TI 2011 - FCC) 56 No RUP, definir quais so
os atores, os casos de uso existentes e como
eles interagem entre si funo tpica do
a) Designer de Negcios.
b) Revisor do Modelo de Negcios.
c) Analista do Processo de Negcios.
d) Revisor de Requisitos.
e) Analista de Sistemas.

83
Exerccios
5. (Infraero Arquitetura de Sistemas Gesto de
TI 2011 - FCC) 57 Uma disciplina do RUP que
tem como uma de suas finalidades "assegurar
que os clientes, usurios e desenvolvedores
tenham um entendimento comum da
organizao- alvo", a qual se relaciona com a
disciplina Ambiente. Trata-se de
a) Requisitos.
b) Anlise e Design.
c) Modelagem de Negcios.
d) Gerenciamento de Configurao e Mudana.
e) Gerenciamento de Projetos.

84
Exerccios
6. (Infraero Arquitetura de Sistemas Gesto de TI
2011 - FCC) 58 Em projetos pequenos, o RUP pode
reduzir os requisitos de artefato para se comparar ao
equivalente de artefatos em projeto de XP. Nesse
sentido, considere o quadro de equivalncia entre os
artefatos do XP e RUP:
Est correto o que consta APENAS em

a) I, II e III.
b) I, II e IV.
c) II, III e V.
d) II, IV e V.
e) III, IV e V.

85
Exerccios
7. (TRT 23 Tecnologia da Informao 2011 - FCC) 34
A disciplina Gerenciamento de Projeto do RUP tem por
finalidade fornecer um framework para gerenciamento
de
I. Projetos especficos de software.
II. Riscos.
III. Oramento.
IV. Contratos.

Est correto o que consta em


a) I e II, apenas.
b) III e IV, apenas.
c) I, II e III, apenas.
d) II, III e IV, apenas.
e) I, II, III e IV.

86
Exerccios
8. (ANA Desenvolvimento de Sistemas e
Administrao 2009 - ESAF) 13 O fluxo de
trabalho de processo RUP que efetua o controle
de alteraes e mantm a integridade dos
artefatos do projeto denominado
a) modelagem de negcio.
b) requisitos.
c) ambiente.
d) gerenciamento de projeto.
e) gerenciamento de configurao.

87
Exerccios
9. (CGU AFC - Desenvolvimento de Sistemas
2008 - ESAF) 32 No Processo Unificado (PU),
o termo Modelo de Domnio significa uma
representao visual de classes conceituais ou
objetos do mundo real. Assinale a opo que
apresenta uma afirmativa correta quanto ao
Modelo de Domnio.
a) No trata da representao de objetos de software.
b) Significa um conjunto de diagramas que descreve classes de
software.
c) Representa a camada de domnio de uma arquitetura de
software.
d) Representa objetos de software com responsabilidades.
e) Aplicando a notao UML, ilustrado como um conjunto de
diagramas de classe em que so definidas as operaes.
88
Exerccios
10.(CGU AFC - Desenvolvimento de Sistemas
2008 - ESAF) 38 A anlise arquitetural, no
processo unificado, pode ser vista como uma
especializao da anlise de requisitos, com
foco nos requisitos que influenciam a
arquitetura. Assinale a opo que se refere
anlise arquitetural.
a) Est preocupada com a identificao e resoluo dos requisitos
no-funcionais do sistema.
b) Faz parte da anlise de riscos de negcio de um projeto.
c) Produz os artefatos de arquitetura de implantao.
d) Enfoca a camada lgica da aplicao principal.
e) Trata do conjunto de decises significativas sobre a organizao
de um sistema de software.

89
Exerccios
11.(CGU AFC - Desenvolvimento de Sistemas
2008 - ESAF) 47 No RUP (Rational Unifi ed
Process), dois dos exemplos dos artefatos de
Implantao so:
a) Guia de design e Arte final do produto.
b) Material de suporte para o usurio e Guia de teste.
c) Plano de implantao e Manual de guia de estilo.
d) Notas de release e Materiais de treinamento.
e) Artefatos de Instalao e Guia de ferramentas.

90
Exerccios
12.(CGU AFC - Desenvolvimento de Sistemas
2008 - ESAF) 48 No RUP (Rational Unified
Process), o termo Papis se refere a

a) pessoas que executam atividades.


b) definio abstrata de um conjunto de atividades executadas e dos
respectivos artefatos.
c) a identificao e responsabilidades de pessoas ou grupo de
pessoas.
d) os cargos ocupados por pessoas.
e) as competncias exigidas para que uma pessoa execute
atividades.

91
Exerccios
13.(CESAN ES Analista de TI 2011 -
Consulplan) 34 Em relao ao RUP, analise as
afirmativas:
I. Usa a abordagem da orientao a objetos em sua concepo.
II. projetado e documentado utilizando a notao UML.
III. As fases do RUP so: concepo, elaborao, construo e
execuo.
IV. Baseia-se nos quatro Ps: Processos, Projeto, Produto e Pontos de
Funo.
Esto corretas apenas as afirmativas:

a) I, II
b) II, III
c) I, II, IV
d) III, IV
e) I, II, III, IV
92
Exerccios
14.(IBGE TI e Comunicao 2009 -
Consulplan) 15 Com relao aos Modelos de
Processo de Software, correto afirmar que:
a) As vantagens do modelo em cascata consistem na documentao
produzida em cada fase, e a sua aderncia a outros processos de
engenharia. Seu maior problema a diviso flexvel do projeto em
estgios distintos.
b) O RUP, principal representante do ciclo de vida de processo
incremental e interativo, dividido nas seguintes fases: concepo,
elaborao, construo e transao.
c) Existem trs tipos fundamentais de desenvolvimento evolucionrio:
exploratrio, explanatrio e prototipao throwaway.
d) As fases do RUP esto relacionadas mais estritamente a assuntos
tcnicos do que aos negcios.
e) A entrega incremental uma abordagem que combina as vantagens
do modelo em cascata e a abordagem evolucionria.
93
Exerccios
15. (Transpetro Analista de Sistemas Junior 2011 Cesgranrio) 29
O Processo Unificado divide a realizao de um projeto para
desenvolvimento de um sistema de software em fases. Em cada
uma dessas fases, so executadas atividades de diversas
disciplinas em diferentes propores. No desenvolvimento de um
sistema de software complexo, esse processo recomenda
a) construir uma arquitetura executvel ao final da fase de construo, para
validar as regras do negcio e os requisitos funcionais do sistema.
b) criar um modelo de casos de uso durante a fase de elaborao, para
documentar as regras do negcio e os requisitos no funcionais do sistema.
c) usar a abordagem de desenvolvimento iterativa e incremental, para dividir
as atividades em iteraes em que cada iterao gera um incremento do
software.
d) ordenar os riscos envolvidos no projeto, para que os riscos menos crticos
sejam considerados logo na fase de iniciao e os mais crticos nas fases
finais.
e) entregar a primeira verso do sistema logo aps a fase de transio, para
evitar os problemas existentes no modelo de ciclo de vida em cascata
tradicional.
94
Exerccios
16.(FINEP Analista Desenvolvimento de
Sistemas 2011 Cesgranrio) 36 No Processo
Unificado (UP), que nome dado diferena (
delta ) entre dois releases do produto ao final de
iteraes subsequentes?

a) Ciclo
b) Iterao
c) Incremento
d) Build
e) Baseline

95
Exerccios
(TRE ES Programao de Sistemas 2011
Cespe) Acerca de RUP (rational unified process),
julgue os itens que se seguem.
17. [72] O conjunto de artefatos de requisitos do RUP
contm artefatos relativos ao planejamento, tais como o
plano de projeto e os planos de iterao.
18. [73] RUP e UML so interdependentes, isto , no h
como se aplicar o RUP no desenvolvimento de um
sistema se no se utilizar o UML.
19. [74] No desenvolvimento de software por meio do RUP,
definem-se marcos de progresso do processo, com
previso de entrega de produtos e decises nas
passagens das fases.

96
Exerccios
(TCU AFCE TI 2010 Cespe) Acerca do
processo unificado de software, julgue os itens
subseqentes.
20. [108] UML (Unified modeling language) uma
tecnologia concorrente com o processo unificado, no
que diz respeito ao apoio prtica de engenharia de
software orientada a objetos.
21. [109] O processo unificado de software centrado na
arquitetura e orientado por casos de uso, o que sugere
um fluxo de processo iterativo e incremental.

97
Infraero Cesan
Gabarito 1. D 13. A
2. D IBGE
3. D 14. E
4. E Transpetro
5. A 15. C
6. C FINEP
TRT 23 16. C
7. A TRE - ES
ANA 17. E
8. E 18. E
CGU 19. C
9. A TCU
10. A 20. E
11. D 21. C
gabrielpacheco@euvoupassar.com.br
12. B www.tiparaconcursos.net
facebook.com/tiparaconcursos
twitter.com/gabrielfpacheco 98
Contedo Programtico.

Anlise e projeto de sistemas:


Anlise e projeto estruturado / Anlise
estruturada.
Anlise e projeto OO.
Conceitos fundamentais.
Anlise.
Modelagem.
Padres de projeto.
UML.

99
100
Anlise e projeto OO
Padres de Projeto
Projetar Software orientado a OO fcil, difcil
projetar OO reutilizvel.
Cada padro de projeto nomeia, explica e avalia um
aspecto de projeto importante e recorrente em
sistemas OO.
Cada padro descreve um problema no nosso
ambiente e o cerne da sua soluo, de tal forma que
voc possa usar essa soluo mais de um milho de
vezes, sem nunca faz-lo da mesma maneira
(Christofer Alexander)

101
Anlise e projeto OO
Padres de Projeto
Descries de objetos e classes comunicantes que
precisam ser personalizadas para resolver um
problema geral de projeto num contexto particular.
Um padro de projeto nomeia, abstrai e identifica os
aspectos-chave da uma estrutura de projeto comum
para torn-la til para a criao de um projeto
orientado a objetos reutilizvel.
Padres de projeto no so projetos.

102
Anlise e projeto OO
Padres de Projeto
Padres de projeto no so projetos.
Um padro comumente se define em:
Nome do Padro.
Problema.
Soluo.
Conseqncias.

103
Anlise e projeto OO
Padres de Projeto Anti-pattern
Padro de projeto que pode ser comumente utilizado
m se apresente ineficiente e improdutivo quando
colocado em prtica.

104
Anlise e projeto OO
Padres de Projeto MVC de Smalltalk
Trs tipos de objetos:
Modelo: objeto de aplicao.
Viso: apresentao na tela.
Controlador: maneira como a interface do usurio reage s
entradas do objeto.
Uma viso dever garantir que a sua aparncia reflita
o estado do modelo (subscribe/notify).
Possui seus principais relacionamentos fornecidos
pelos padres Observer, Composite e Strategy.

105
106
Anlise e projeto OO
Padres de Projeto Classificao
Os padres de projetos podem ser agrupados por:
Finalidade:
Criao: criao de objetos.
Estrutural: composio de classes ou de objetos.
Comportamental: caracterizam a maneira pelas quais classes ou
objetos interagem e distribuem responsabilidades.
Escopo:
Classes: relacionamentos entre classes e subclasses.
Objetos: lidam com relacionamentos entre objetos que podem ser
mudados em tempo de execuo.

107
Anlise e projeto OO
Padres de Projeto Classificao
Propsito
De criao Estrutural Comportamental
Escopo Classe Factory Method Adapter (class) Interpreter
Template Method
Objeto Abstract Factory Adapter (object) Chain of
Responsability
Builder Bridge Command
Prototype Composite Interator
Singleton Decorator Mediator
Faade Memento
Flyweight Observer
Proxy State
Strategy
Visitor
108
109
Anlise e projeto OO
Padres de Projeto Framework
uma tcnica da Orientao a Objetos, voltada para
a reutilizao que se beneficia de trs caractersticas
das linguagens de programao orientadas a objetos:
abstrao, polimorfismo e herana.
Descreve a arquitetura de um sistema orientado a
objetos, os tipos de objetos e as interaes entre os
mesmos.

110
Anlise e projeto OO
Padres de Projeto Framework
Ele pode ser vislumbrado como o esqueleto
template de uma aplicao que pode ser
customizado pelo programador e aplicado a um
conjunto de aplicaes de um mesmo domnio.
Com frameworks no se busca apenas reutilizar
simples componentes de software, mas subsistemas,
aumentando assim o grau de reutilizao e
contribuindo para uma melhor qualidade do produto
software.

111
Anlise e projeto OO
Padres de Projeto Problemas solucionados
Procurando objetos apropriados (decomposio em
objetos).
Determinando a granularidade de objetos (o que
deve ser um objeto).
Especificando interfaces de objetos (interface =
conjunto de assinaturas, encapsulamento e
polimorfismo).
Especificando implementaes de objetos (classe,
operaes, atributos e objetos; herana,
polimorfismo).

112
Anlise e projeto OO
Padres de Projeto Problemas solucionados
Colocando os mecanismos de reutilizao para
funcionar (herana, composio e delegao).

113
Anlise e projeto OO
Padres de Projeto Padres de Criao
Abstraem o processo de instanciao.
Ajudam a tornar um sistema independente de como
seus objetos so criados, compostos e
representados.
Um padro de criao de classe usa herana para
para variar a classe que instanciada, um padro de
criao de objeto delegar a instanciao para outro
objeto.

114
Anlise e projeto OO
Padres de Projeto Padres de Criao
Padres de criao voltados para classes deixam
alguma parte da criao de objetos para as
subclasses, enquanto que os padres de criao
voltados para objetos postergam esse processo para
outro objeto.

115
Anlise e projeto OO
Padres de Projeto Padres de Criao
Padres de criao voltados para classes deixam
alguma parte da criao de objetos para a
subclasses, enquanto que os padres de criao
voltados para objetos postergam esse processo para
outro objeto.
Caractersticas recorrentes:
Todos encapsulam conhecimento sobre quais classes
concretas so usadas pelo sistema.
Ocultam o modo como as instncias destas classes so
criadas e compostas.

116
Anlise e projeto OO
Padres de Projeto Abstract Factory (KIT)
Fornece uma interface para criao de famlias de
objetos relacionados ou dependentes sem
especificar suas classes concretas.

117
Anlise e projeto OO
Padres de Projeto Abstract Factory (KIT)
Use quando:
Um sistema deve ser independente de como seus
produtos so criados, compostos ou representados.
Um sistema deve ser configurado como um produto de
uma famlia de mltiplos produtos.
Uma famlia de objetos-produtos for projetada para ser
usada em conjunto, e voc necessita garantir essa
restrio.
Voc quer fornecer uma biblioteca de classes de produtos
e quer revelar somente suas interfaces, no suas
implementaes.

118
Anlise e projeto OO
Padres de Projeto Abstract Factory (KIT)

119
Anlise e projeto OO
Padres de Projeto Abstract Factory (KIT)
Participantes:
AbstractFactory: declara uma interface para operaes que
criam objetos-produto abstratos.
ConcreteFactory: implementa as operaes que criam
objetos-produto concretos.
AbstractProduct: declara uma interface para um tipo de
objeto-produto.
ConcreteProduct: define um objeto-produto a ser criado
pela correspondente fbrica concreta. Implementa a
interface de AbstractProduct.
Client.

120
Anlise e projeto OO
Padres de Projeto Builder
Separa a construo de um objeto complexo da sua
representao de modo que o mesmo processo de
construo possa criar direfentes representaes.

121
Anlise e projeto OO
Padres de Projeto Builder
Use quando:
Um algoritmo para criao de um objeto complexo deve
ser independente das partes que compem o objeto e de
como elas so montadas.
O processo de construo deve permitir diferentes
representaes para o objeto que construdo.

122
Anlise e projeto OO
Padres de Projeto Builder

123
Anlise e projeto OO
Padres de Projeto Builder
Participantes:
Builder: especifica uma interface abstrata para criao de
partes de um objeto-produto.
ConcreteBuilder: constri e monta partes do produto pela
implementao da interface de builder, define e mantm a
representao que cria, fornece uma interface para
recuperao do produto.
Director: constri um objeto usando a interface de builder.
Product: representa o objeto complexo em construo,
inclui classes que definem as partes constituintes, inclusive
as interfaces para a montagem das partes no resultado
final.

124
Anlise e projeto OO
Padres de Projeto Factory Method (visual
constructor)
Definir uma interface para criar um objeto, mas
deixar as subcalsses decidirem que classe instanciar.

125
Anlise e projeto OO
Padres de Projeto Factory Method (visual
constructor)
Use quando:
Uma classe no pode antecipar a classe de objetos que
deve criar.
Uma classe quer que suas subclasses especifiquem os
objetos que criam.
Classes delegam responsabilidade para uma dentre vrias
subclasses auxiliares, e voc quer localizar o conhecimento
de qual subclasse auxiliar que a delegada.

126
Anlise e projeto OO
Padres de Projeto Factory Method (visual
constructor)

127
Anlise e projeto OO
Padres de Projeto Factory Method (visual
constructor)
Participantes:
Product: define a interface de objetos que o mtodo cria.
ConcreteProduct: implementa a interface de Product.
Creator: declara o mtodo Factory, o qual retorna um
objeto tipo Product.

128
Anlise e projeto OO
Padres de Projeto Prototype
Especifica os tipos de objetos a serem criados
usando uma instncia-prottipo e cria novos objetos
pela cpia desse prottipo.

129
Anlise e projeto OO
Padres de Projeto Prototype
Use quando:
Quando as classes a instanciar forem especificadas em
tempo de execuo.
Para evitar a construo de uma hierarquia de classes de
fbricas paralela hierarquia de classes de produto.
Quando as instncias de uma classe puderem ter uma
dentre poucas combinaes diferentes de estados.

130
Anlise e projeto OO
Padres de Projeto - Prototype

131
Anlise e projeto OO
Padres de Projeto Prototype
Participantes:
Prototype: declara uma interface para clonar a si prprio.
ConcretePrototype: implementa uma operao para clonar
a si prprio.
Client: cria um novo objeto solicitando a um prottipo que
clone a si prprio.

132
Anlise e projeto OO
Padres de Projeto Singleton
Garante que uma classe tenha somente uma
instncia e fornece um ponto global de acesso para a
mesma.

133
Anlise e projeto OO
Padres de Projeto Singleton
Use quando:
For preciso haver apenas uma instncia de uma classe, e
essa instncia tiver que dar acesso aos clientes atravs de
um ponto bem conhecido.
A nica instncia tiver de ser extensvel atravs de
subclasses, possibilitando aos clientes usar uma instncia
estendida sem alterar o seu cdigo.

134
Anlise e projeto OO
Padres de Projeto - Singleton

135
Anlise e projeto OO
Padres de Projeto Singleton
Participantes:
Singleton: define uma operao Instance que permite aos
clientes acessarem sua nica instncia. Pode ser
responsvel pela criao da sua prpria instncia nica.

136
Anlise e projeto OO
Padres de Projeto Padres estruturais
Preocupam-se com a forma como classes e objetos
so compostos para formar estruturas maiores.
Os padres estruturais de classes utilizam a herana
para compor interfaces ou implementaes. Os
padres estruturais de objetos descrevem maneiras
de compor objetos para obter novas funcionalidades.

137
Anlise e projeto OO
Padres de Projeto Adapter
Converte a interface de uma classe em outra
interface, esperada pelos clientes. O adapter permite
que classes com interfaces incompatveis trabalhem
em conjunto.

138
Anlise e projeto OO
Padres de Projeto Adapter
Use quando:
Voc quiser usar uma classe existente, mas sua interface
no corresponder interface de que necessita.
Voc quiser criar uma classe reutilizvel que coopere com
classes no-relacionadas ou no-previstas, ou seja, classes
que no necessariamente tenham interfaces compatveis.
Voc precisar usar vrias subclasses existentes, porm, for
impraticvel adaptar essas interfaces criando subclasses
para cada uma. Um adaptador de objeto pode adaptar a
interface de sua classe-me.

139
Anlise e projeto OO
Padres de Projeto - Adapter

Adaptador de classe depende herana mltipla.

140
Anlise e projeto OO
Padres de Projeto - Adapter

Adaptador de objeto depende da composio de


objetos.
141
Anlise e projeto OO
Padres de Projeto Adapter
Participantes:
Target: define a interface especfica do domnio que Client
usa.
Client: colabora com objetos compatveis com a interface
de Target.
Adaptee: define uma interface existente que necessita ser
adaptada.
Adapter: adapta a interface do Adaptee interface de
Target.

142
Anlise e projeto OO
Padres de Projeto Bridge (Handle/Body)
Desacopla uma abstrao da sua implementao, de
modo que as duas possam variar independente.

143
Anlise e projeto OO
Padres de Projeto Bridge (Handle/Body)
Use quando:
Desejar evitar um vnculo permanente entre uma
abstrao e sua implementao.
Tanto as abstraes como suas implementaes tiverem
de ser extensveis por meio de subclasses.
Mudanas na implementao de uma abstrao no
puderem ter impacto sobre os clientes.
Tiver uma proliferao de classes.
Desejar compartilhar uma implementao entre mltiplos
objetos e este fato deve estar oculto no cliente.

144
Anlise e projeto OO
Padres de Projeto Bridge (Handle/Body)

145
Anlise e projeto OO
Padres de Projeto Bridge (Handle/Body)
Participantes:
Abstraction: define a interface da abstrao, mantm uma
referncia para um objeto do tipo implementator.
RefineAbstraction: estende a interface definida por
Abstraction.
Implementor: define a interface para as classes de
implementao.
ConcreteImplementor: implementa a interface de
Implementor e define a sua implementao concreta.

146
Anlise e projeto OO
Padres de Projeto Decorator
Dinamicamente, agrega responsabilidades adicionais
a um objeto.
Fornece uma alternativa flexvel ao uso de subclasses
para extenso de funcionalidades.

147
Anlise e projeto OO
Padres de Projeto Decorator
Use quando:
Para acrescentar responsabilidades a objetos individuais
de forma dinmica e transparente, ou seja, sem afetar
outros objetos.
Para responsabilidades que podem ser removidas.
Quando a extenso atravs do uso de subclasses no
prtica.

148
Anlise e projeto OO
Padres de Projeto Decorator

149
Anlise e projeto OO
Padres de Projeto Decorator
Participantes:
Component: define a interface para objetos que podem ter
responsabilidades acrescentadas aos mesmos
dinamicamente.
ComcreteComponent: define um objeto para o qual
responsabilidades adicionais podem ser atribudas.
Decorator: mantm uma referncia para uma objeto
Component e define uma interface que segue a interface
de Component.
ConcreteDecorator: acrescenta responsabilidades ao
componente.

150
Anlise e projeto OO
Padres de Projeto Faade
Fornece uma interface unificada para um conjunto
de interfaces em um subsistema.
Define uma interface de nvel mais alto que torna o
subsistema mais fcil de ser usado.

151
Anlise e projeto OO
Padres de Projeto Faade
Use quando:
Voc desejar fornecer uma interface simples para um
subsistema complexo.
Existirem muitas dependncias entre clientes e classes de
implementao de uma abstrao.
Voc desejar estruturar seus subsistemas em camadas.

152
Anlise e projeto OO
Padres de Projeto Faade

153
Anlise e projeto OO
Padres de Projeto Faade
Participantes:
Faace: conhece quais as classes do subsistema so
responsveis pelo atendimento de uma solicitao. Delega
solicitaes de clientes e objetos apropriadas do
subsistema.
Classes de subsistema: implementam a funcionalidade do
subsistema. Encarregam-se do trabalho atribudo a elas
pelo objeto Faade. No tem conhecimento da faade, no
mantm referncias com ela.

154
Anlise e projeto OO
Padres de Projeto Padres comportamentais
Preocupam-se com algoritmos e a atribuio de
responsabilidades entre objetos.
No descrevem apenas padres de objetos ou
classes, mas tambm os padres de comunicao
entre eles.
Caracterizam fluxos de controle difceis de seguir em
tempo de execuo.
Traz o foco para como os objetos so
interconectados.

155
Anlise e projeto OO
Padres de Projeto Padres comportamentais
Os padres comportamentais de classe utilizam a
herana para distribuir o comportamento entre
classes.
Os padres comportamentais de objetos utilizam a
composio de objetos em vez de herana.

156
Anlise e projeto OO
Padres de Projeto Command
Encapsula uma solicitao como uma objeto, desta
forma permitindo parametrizar clientes com
diferentes solicitaes, enfileirar ou fazer o registro
de solicitaes e suportar operaes que podem ser
desfeita.

157
Anlise e projeto OO
Padres de Projeto Command
Use quando:
Parametrizar objetos por uma ao a ser executada.
Especificar, enfileirar e executar solicitaes em tempos
diferentes.
Suportar, desfazer operaes.

158
Anlise e projeto OO
Padres de Projeto Command

159
Anlise e projeto OO
Padres de Projeto Command
Participantes:
Command: declara uma interface para a execuo de uma
operao.
ConcreteCommand: define uma vinculao entre um
objeto Receiver e uma ao. Implementa Execute atravs
da invocao das correspondentes operaes no Receiver.
Cliente: cria um objeto ConcreteCommand e estabelece o
seu receptor.
Invoker: solicita ao Command a execuo da solicitao.
Receiver: sabe como executar as operaes associadas a
uma solicitao. Qualquer classe pode funcionar como
Receiver.

160
Anlise e projeto OO
Padres de Projeto Observer
Definir uma dependncia um-para-muitos entre
objetos, de maneira que quando um objeto muda de
estado todos os seus dependentes so notificados e
atualizados automaticamente.

161
Anlise e projeto OO
Padres de Projeto Observer
Use quando:
Uma abstrao tem dois aspectos, um dependente do
outro.
Uma mudana em um objeto exige mudanas em outros, e
voc no sabe quantos objetos necessitam ser mudados.
Quando um objeto deveria ser capaz de notificar outros
objetos sem fazer hipteses, ou usar informaes, sobre
quem so esses objetos.

162
Anlise e projeto OO
Padres de Projeto Observer

163
Anlise e projeto OO
Padres de Projeto Observer
Participantes:
Subject: conhece os seus observadores. Fornece uma
interface para acrescentar e remover objetos, permitindo
associar e desassociar objetos Observer.
Observer: defina uma interface de atualizao para objetos
que deveriam ser notificados sobre mudanas em um
subject.
ConcreteSubjet: armazena estados de interesse para
objetos ConcreteObserver. Envia uma notificao para os
seus observadores quando seu estado muda.
ConcreteObserver: mantm uma referncia para um
objeto ConcreteSubject. Armazena estados que deveriam
permanecer consistentes com os do Subject. Implementa a
interface de atualizao de Observer. 164
Anlise e projeto OO
Padres de Projeto Strategy
Definir uma famlia de algoritmos, encapsular cada
uma delas e torn-las intercambiveis.
Permite que o algoritmo varie independentemente
dos clientes que o utilizam.

165
Anlise e projeto OO
Padres de Projeto Strategy
Use quando:
Muitas classes relacionadas diferem somente no seu
comportamento.
Voc necessita de variantes de um algoritmo.
Um algoritmo usa dados dos quais os clientes no
deveriam ter conhecimento.
Uma classe defina muitos comportamentos, e estes
aparecem em suas operaes com mltiplos comandos
condicionais da linguagem.

166
Anlise e projeto OO
Padres de Projeto Strategy

167
Anlise e projeto OO
Padres de Projeto Strategy
Participantes:
Strategy: define uma interface comum para todos os
algoritmos suportados.
ConcreteStrategy: implementa o algoritmo usando a
interface de Strategy.
Context: configurado com um objeto ConcreteStrategy.
Mantm uma referncia para um objeto Strategy. Pode
definir uma interface que permite a Strategy acessar seus
dados.

168
Exerccios
1. (CVM Analista de Sistemas 2010 ESAF)
Uma conexo de instncia
a) uma notao de referncia que define uma relao
especfica entre os objetos de uma instncia.
b) uma notao de modelagem que define uma relao
especfica entre as instncias de um objeto.
c) um recurso de modelagem que define uma ligao entre
componentes de memria.
d) uma notao de implementao que define uma estrutura
de relaes entre objetos instanciados e no instanciados.
e) uma estrutura de modelagem que define objetos
pertinentes a uma instncia.

169
Exerccios
2. (Transpetro Analista de Sistemas Junior - 2010
Cesgranrio) 40 Relacione os padres de projeto
s suas indicaes de uso.

As associaes corretas so:

a) I - P , II - Q , III R
b) I - Q , II - P , III S
c) I - Q , II - R , III P
d) I - R , II - P , III S
e) I - S , II - R , III Q

170
Exerccios
3. (Inmetro Arquitetura de Solues de Software -
2010 Cesgranrio) 32 Com relao aos design
patterns, anti-patterns e projetos orientados a
objeto, assinale a opo correta.
a) Os design patterns s devem ser aplicados a arquiteturas de software
desenvolvido com linguagem orientada a objetos, sendo exemplos de
patterns: Abstract Factory, Singleton, Faade, Builder, Prototype etc.
b) O projeto orientado a objetos uma abordagem para projeto de
software na qual os componentes da arquitetura de um software so
representados por objetos aos quais esto associadas funes, que
sero refinadas posteriormente para operaes, quando da
implementao do software em uma linguagem de programao.
c) A evoluo de um sistema de software mais complexa quando se
opta pelo projeto orientado a objetos.

171
Exerccios
d) Os anti-patterns destacam problemas comuns que as organizaes
desenvolvedoras de software enfrentam em temas organizacionais de
gesto de projeto, de desenho ( design ), de programao, de
gerncia de configurao, entre outros, e fornecem orientaes para
que esses problemas sejam reconhecidos e as suas causas
subjacentes, determinadas.
e) As classes que compem um software desenvolvido segundo os
princpios do projeto orientado a objetos devem ser implementadas
sequencialmente, tendo em vista que, por princpio, as dependncias
de colaborao e responsabilidade estabelecidas entre os mdulos do
projeto no devem possuir ciclos.

172
Exerccios
4. (TRT 4 TI - 2011 FCC) 59 O catlogo de
padres de projeto (design patterns) do GoF
contm
a) 20 padres e est basicamente dividido em duas sees: Structural e
Behavioral.
b) 21 padres e est basicamente dividido em duas sees: Creational e
Behavioral.
c) 23 padres e est basicamente dividido em duas sees: Structural e
Behavioral.
d) 23 padres e est, basicamente, dividido em trs sees: Creational,
Structural e Behavioral.
e) 24 padres e est basicamente dividido em trs sees: Creational,
Spectral e Behavioral.

173
Exerccios
5. (TRT 9 TI - 2010 FCC) 36 Sobre design
pattern considere:
I. No framework pode incluir cdigo de programao e conter
vrios design patterns.
II. No design pattern pode incluir cdigo de programao e
conter vrios frameworks.
III. Os design patterns so bastante abstratos e os frameworks
menos abstratos.
Est correto o que consta em
a) I e III, apenas.
b) I e II, apenas.
c) II e III, apenas.
d) III, apenas.
e) I, II e III.
174
Exerccios
6. (TRF 4 Informtica - 2010 FCC) 64 Sobre os
design patterns, correto afirmar:
a) So aplicaes, propriamente ditas, dedicadas aos domnios de
aplicaes especficos, tais como sistemas de telecomunicaes ou
financeiros.
b) No so complexos e necessita-se de um tempo mnimo para
aprender a us-los.
c) O princpio geral de englobamento de experincia em um padro
aplicvel apenas abordagem de projeto de software orientado a
objetos.
d) O padro uma descrio de conhecimento e experincia
acumulados, uma soluo comprovada para um problema comum.
e) Padres e linguagens de padres so maneiras de implementar
sistemas orientados a objetos por meio da captao da experincia de
programadores. Os padres, apesar de abstratos, sempre incluem
algum cdigo de programao.

175
Exerccios
(ANATEL Arquitetura de Solues 2009 Cespe)
Conforme o SWEBOK, corpo de conhecimento da engenharia
de software, a engenharia de software a aplicao de uma
abordagem sistemtica, disciplinada e quantificada ao
desenvolvimento, operao e manuteno de software. Julgue
os itens a seguir acerca das informaes apresentadas e dos
conceitos de engenharia de software.
7. [92] Entre as metodologias de desenvolvimento de software
atualmente empregadas destacam-se as abordagens embasadas no
modelo unificado e as abordagens geis. O uso das tcnicas de test-
driven design, refactoring, design patterns e pair programming , entre
os modelos acima, maior nas abordagens do modelo unificado. Por
outro lado, o uso de ferramentas CASE-UML mais comum nas
abordagens geis.

176
Exerccios
(Dataprev Desenvolvimento de Software 2006 Cespe)
Com relao a padres de projeto ( design patterns ), julgue
os itens que se seguem.
8. [67] As seguintes situaes justificam o uso do padro Abstract
Factory: o sistema deve ser independente de como os objetos so
criados; o sistema deve poder ser configurado com diferentes famlias
de classes; necessrio garantir que certas classes sejam usadas em
conjunto.
9. [68] As seguintes situaes justificam o uso do padro Adapter:
necessrio um objeto local que se faa passar por um objeto
localizado em outro espao de endereamento; necessrio controlar
o acesso a um objeto; um objeto persistente deve ser carregado em
memria somente quando for referenciado.

177
Exerccios
(Dataprev Desenvolvimento de Software 2006 Cespe)
Com relao a padres de projeto ( design patterns ), julgue
os itens que se seguem.
10. [69] As seguintes situaes justificam o uso do padro Command: um
conjunto de objetos se comunica de forma definida porm complexa, o
que resulta em interdependncias difceis de serem entendidas; o
reso est sendo dificultado pois cada objeto se comunica com vrios
outros objetos.
11. [70] As seguintes situaes justificam o uso do padro Strategy:
necessrio configurar uma classe com uma variedade de
comportamentos; uma classe usa diferentes variaes de um
algoritmo; o mtodo de uma classe tem muitos enunciados
condicionais pois a classe tem comportamentos variados.

178
CVM Anatel
Gabarito 1. B 7. E
Transpetro Dataprev
2. C 8. C
Inmetro 9. E
3. C 10. E
TRT 4 11. C
4. D
TRT 9
5. A
TRF 4
6. D

gabrielpacheco@euvoupassar.com.br
www.tiparaconcursos.net
facebook.com/tiparaconcursos
twitter.com/gabrielfpacheco 179

Potrebbero piacerti anche