Вы находитесь на странице: 1из 56

Curso de Especializao DEINF - UFMA

Desenvolvimento Orientado a Objetos


Prof. Geraldo Braz Junior
Processo Unificado
Referncias: Medeiros, E. Desenvolvendo Software com UML 2.0: Definitivo, Makron Books, 2006.
Pressman, R. S. Engenharia de Software, McGraw-Hill, 6. Edio, 2006
Sommerville, I. Engenharia de Software, 8 edio, 2007.
Sumrio
Breve Histrico
Caractersticas
Ciclo de Vida
Fluxos de Trabalho
Os artefatos do PU
RUP
2
Introduo
O processo unificado encaixa-se na definio de processo:
Um conjunto de atividades executadas para transformar um
conjunto de requisitos do cliente em um sistema de software.
O PU tambm uma estrutura genrica de processo que
pode ser customizado adicionando-se ou removendo-se
atividades com base nas necessidades especficas e nos
recursos disponveis para o projeto.
3
Histrico
O PU tem suas razes no trabalho feito por Ivar Jacobson na
decada de 60;
Em 87 Jacobson deixou a empresa Ericsson, em que trabalhava,
iniciando uma companhia chamada Objectory AB;
Desenvolveram o Objectory, que era semelhante em estrutura
com(Processo e Protudo) ao que hoje o RUP;
Seu livro Object-Oriented Software Engineering foi um marco na
comunidade OO;
4
Histrico
Alguns anos apos a Rational comprou a Objectory AB;
Em 94 foi construido o Processo Objectory da Rational (ROP) em
paralelo com o Mtodo Unificado, que depois foi chamado de
UML;
Em 98 a Rational mudou o nome do produto-processo para RUP.
5
Histrico
Apesar do PU utilizar a UML para atividades de modelagem, eles
so intrinsecamente separados
A UML independente de processo.
Qualquer que seja o processo usado no desenvolvimento de um
projeto, a UML poder ser utilizada para registrar as decises de
anlise e de projeto resultantes
6
Caractersticas do PU
um framework genrico de um processo de desenvolvimento
baseado em componentes que realizam as interfaces
Utiliza toda a definio da UML
Alicerces:
Dirigido por Casos de Uso
Centrado na Arquitetura
Desenvolvimento iterativo e incremental
os 4 Ps:pessoa, projeto, produto e processo
7
P4 = Pessoa, Projeto, Produto,
Processo
PESSOAS financiam, escolhem, desenvolvem,
gerenciam, testam, usam e so beneficiadas por
produtos
PROJETOS sofrem alteraes. Determinam os tipos
de pessoas que iro trabalhar no projeto e os artefatos
que sero usados
ARTEFATO qualquer tipo de informao criada por uma
pessoa (diagramas UML, textos, modelos de interfaces)
8
P4 = Pessoa, Projeto, Produto,
Processo
PRODUTO cdigo fonte, cdigo de mquina,
subsistemas, classes, diagramas: interao, de estados e
outros artefatos
PROCESSO define quem (papel/pessoa/
trabalhadores) faz o que (artefato), quando
(disciplina) e como (atividades)
PU um processo. Considera fatores organizacionais, do
domnio, ciclo de vida e tcnicos
9
Trabalhadores e Atividades
Trabalhadores: Um trabalhador algum que
desempenha um papel e responsvel pela
realizao de atividades para produzir ou modificar
um artefato. Exemplos: analista de sistemas, programador,
testador etc.
Atividades: tarefa que um trabalhador executa a fim de
produzir ou modificar um artefato.
10
Disciplinas
Descreve as seqncias das atividades que produzem algum
resultado significativo e mostra as interaes entre os
participantes
So realizadas a qualquer momento durante o ciclo de
desenvolvimento (Fases do PU)
Ex. Requisitos, Anlise, Projeto, Implementao e Teste
11
Dirigido por Casos de Uso
Um caso de uso uma seqncia de aes, executadas
por um ou mais atores, que produz um ou mais
resultados de valor para um ou mais atores.
Um ator uma pessoa ou outro sistema.
Os casos de uso possibilitam que os requisitos funcionais
possam ser capturados na perspectiva de cada um dos
usurios do sistema
Definir comportamento, validao
12
Casos de Uso
Arquitetura do sistema
dirige
influi
Por que Casos de Uso?
Os requisitos funcionais so registrados preferencialmente por
meio deles
Eles ajudam a planejar as iteraes
Eles podem conduzir o projeto
O teste baseado neles.
Modelo casos de uso = casos de uso =
funcionalidade do sistema
13
Dirigido a Casos de Uso - Ilustrao
14
<arquivo>
Classe de
fronteira
Classe de
controle
Classe de
entidades
Modelo
USE-CASE
Modelo
ANLISE
Modelo
PROJETO
Classe
Modelo
IMPLEMENT
<executvel>
<arquivo>
relacionamento
Centrado na arquitetura
Uma arquitetura um mapa do sistema:
Define partes do mesmo
Relacionamentos
Interaes
Mecanismos de interconexo,
Por isso, importante definir uma arquitetura cedo e
refin-la com o tempo.
15
Centrado na arquitetura
O Processo Unificado centrado na arquitetura e esta
descrita como diferentes vises do sistema, sendo
influenciada pelos casos de uso, sistemas existentes,
plataforma de desenvolvimento, framework, etc.
A arquitetura importante porque:
Ajuda a entender a viso global
Ajuda a organizar o esforo de desenvolvimento
Facilita as possibilidades de reuso
Facilita a evoluo do sistema
Tem base nos casos de uso especificados.
16
Centrado na arquitetura
Casos de Uso
Plataforma de software
Disponibilidade de blocos
reusveis
Sistemas existentes
Hardware existente
Requisitos no-funcionais
(performance, segurana)
Arquitetura
influem
17
Desenvolvimento Iterativo e
Incremental
O PU basicamente um processo de
desenvolvimento iterativo e incremental, no qual
o software no implementado a partir de um
instante no fim do projeto, mas ao contrrio, o
ciclo de vida no PU desenvolvido e
implementado em iteraes.
Uma iterao um miniprojeto que resulta em
uma verso do sistema liberada interna ou
extermamente;
Essa verso oferece uma melhora incremental
sobre a iterao anterior.
18
Desenvolvimento Iterativo e
Incremental
Para cada iterao os desenvolvedores tero que
identificar e especificar os casos de usos relevantes,
desenvolver a atividade usando a arquitetura escolhida
como guia, implementar o modelo de design em
componentes e verificar se estes satisfazem os casos de
uso.
Benefcios:
Identificao de riscos adiantada
Preparao do sistema para requisitos que mudam
Integrao contnua (facilita testes) e aprendizado facilitado
Resultado de uma iterao: incremento.
19
Incremento
20
Sistema(i)
Sistema(i)+1
ciclo
fase
iterao
Ciclo de Vida
O Processo Unificado consiste de vrias interaes no
ciclo de vida de um sistema.
O ciclo formado por quatro fases:
Concepo
Elaborao
Construo
Transio
Cada fase, por sua vez, subdivida em iteraes que
passam por todos os cincos fluxos do trabalho do
processo:
Requisitos, Anlise, Projeto, Implementao e Teste.
21
Ciclo de Vida
22
Concepo
O objetivo estabelecer a viabilidade do sistema proposto.
Nessa fase se faz:
Definio do escopo do sistema.
Estimativas de custos e cronograma
Identificao dos potenciais riscos que devem ser gerenciados ao
longo do projeto
Esboo da arquitetura do sistema, que servir como alicerce
para a sua construo.
Cada iterao est voltada para a produo de casos de uso de
negcio e da arquitetura preliminar
23
Elaborao
O objetivo capturar o que pode ser feito no sistema com as
restries financeiras e outras questes levantadas.
Nessa fase se faz:
Captura dos requisitos funcionais da aplicao (que no foram
capturados na fase de concepo).
Expanso do esboo da arquitetura para uma arquitetura base para o
desenvolvimento do sistema.
Abordagem dos riscos significativos.
Elaborao de um plano com questes econmicas indicando
como o projeto vai evoluir na fase de construo.
24
Elaborao
Vrios dos casos de uso so especificados com detalhes; a
arquitetura do sistema projetada
A arquitetura expressa em vises dos modelos do
sistema:
modelo de casos de uso
modelo de anlise
modelo de projeto
modelo de implementao
modelo de distribuio
O resultado da fase o conjunto dos modelos acrescidos
de elementos de implementao
25
Construo
Nesta fase, as iteraes esto voltadas para a produo de
mdulos executveis, culminando com o
desenvolvimento de um produto pronto para entrega
comunidade de usurios
Durante esta fase o produto construdo
O sistema torna-se um produto pronto para ser posto
disposio da comunidade de usurios
26
Construo
A arquitetura estvel, ainda que possa ser
aperfeioada
Ao final da fase, o sistema conter todos os casos
de uso que gernciam e usurios concordaram em
desenvolver para esta verso do produto
Erros podero ser encontrados e sero corrigidos
27
Transio
Compreende o perodo em que o produto passa para
beta-teste; a primeira verso entregue aos usurios
A fase envolve atividades de treinamento de usurios,
assistncia de uso do produto e correo de defeitos
encontrados aps a entrega
Um pequeno nmero de usurios experientes utiliza o
produto e reporta os erros e inadequaes encontradas
Os desenvolvedores corrigem os erros e incorporam
melhorias
28
Ciclo de Vida
29
Fluxos de Trabalho
Avaliando-se as fases do PU, pode-se ter a impresso de
que cada ciclo de iterao comporta-se como o modelo
em cascata.
Mas isso no verdade:
paralelamente s fases do PU, os fluxos de trabalho
(requisitos, anlise, projeto, implementao, testes),
denominados disciplinas do PU, so realizados a qualquer
momento durante o ciclo de desenvolvimento.
Disciplinas podem ter maior nfase durante certas fases
e menor nfase em outras
30
Fluxo: Requisitos
Durante o fluxo de trabalho, os requisitos do sistema so
especificados atravs da identificao das necessidades de
usurios e clientes
Estes requisitos funcionais so expressos em casos de uso
atravs do modelo de casos de uso
O modelo de casos de uso desenvolvido em vrios
incrementos, onde as iteraes iro adicionar novos casos
de uso e/ou adicionar detalhes as descries dos casos de
uso existentes.
31
Requisitos
Durante a fase de concepo, os casos de uso
mais importantes so identificados, delimitando o
domnio do sistema.
Durante a fase de elaborao, a maioria dos
requisitos remanescentes capturada, assim
desenvolvedores podero saber o quo devero se
empenhar para desenvolver o sistema
32
Requisitos
Ao final da fase de elaborao, devem ter sido capturados
e descritos cerca de 80% dos requisitos do sistema
Porm, apenas 5% a 10% destes requisitos so
implementados nesta fase
Os requisitos que sobram so capturados e
implementados durante a fase de construo.
Na fase de transio quase no h requisitos a serem
capturados, a menos que ocorram mudanas nos
mesmos.
33
Anlise
O produto do fluxo de anlise o modelo de
anlise.
O modelo tem a funo de refinar os requisitos
especificados no fluxo anterior (fluxo de
requisitos) atravs da construo de diagramas de
classes conceituais permitindo, desta forma,
argumentao a respeito do funcionamento
interno do sistema.
34
Anlise
O modelo de anlise fornece mais poder
expressivo e formalismo como diagramas de
interaes (Sequncia ou Comunicao)e diagrama
de estados que representam a dinmica do
sistema.
O fluxo de anlise tem maior importncia
durante fase de elaborao
Isso contribui para a definio de uma arquitetura
estvel e facilita o entendimento detalhado dos
requisitos.
35
Projeto
No fluxo de projeto o sistema moldado e sua
forma definida de maneira a suprir as
necessidades especificadas pelos requisitos.
Define um modelo de projeto que construdo
com base no modelo de anlise definido no fluxo
anterior.
O fluxo de projeto desenvolve o modelo de
projeto que descreve o sistema em um nvel
fsico.
36
Projeto
A funo principal deste fluxo obter uma compreenso
detalhada dos requisitos do sistema, levando em
considerao fatores como linguagens de programao,
SO, tecnologias de banco de dados, interface com o
usurio, etc.
O fluxo de projeto possui seu enfoque entre o fim da
fase de elaborao e o incio da fase de construo.
Este fluxo serve de base para o fluxo de implementao
37
Projeto
Os mesmos diagramas citados nos fluxos anteriores so
construdos em um nvel mais fsico que conceitual
O fluxo de projeto tambm podem utilizar o diagrama
de objetos
Enquanto que o fluxo de anlise se interessa por
o que o sistema de fazer, o fluxo de projeto diz
respeito a como os requisitos sero
implementados
38
Implementao
O fluxo de implementao baseado no modelo de
projeto
Implementa o sistema em termos de componentes
(cdigo fonte, executvel, etc).
A maior parte da arquitetura do sistema definida
durante o projeto.
39
Implementao
O modelo de implementao se limita:
1. Planejar as integraes do sistema em cada iterao. O
resultado um sistema que implementado como uma
sucesso de etapas pequenas e gerenciveis
2. Implementar os subsistemas encontrados durante o projeto
3. Testar as implementaes e integr-los, compilando-as em
um ou mais arquivos executveis, antes de envia-los ao fluxo
de teste.
40
Implementao
Este fluxo tem maior importncia na fase de
construo e apesar de ter suas caractersticas prprias,
a maior parte de suas atividades realizada de forma
quase mecnica, pelo fato das decises mais difceis
terem sido tomadas durante o fluxo de projeto.
O cdigo gerado durantes a implementao, deve ser
uma simples traduo das decises de projeto em uma
linguagem especfica.
41
Teste
O fluxo de teste desenvolvido com base no produto
do fluxo de implementao.
Os componentes executveis so testados
exaustivamente no fluxo de teste para ento ser
disponibilizados aos usurios finais.
O principal propsito do fluxo de teste realizar
vrios testes e sistematicamente analisar os resultados
de cada teste.
42
Teste
Componentes que possurem defeitos retornaro a
fluxos anteriores como os fluxos de projeto e
implementao, onde os problemas encontrados
podero ser corrigidos.
Um planejamento inicial de testes pode ser feito j na
fase concepo.
43
Teste
A maior parte dos testes so feitos durante a fase de
elaborao, quando a arquitetura do sistema definida,
e durante a fase de construo quando o sistema
implementado.
Na fase de transio, o fluxo de testes se limita a
correo de defeitos encontrados durante a utilizao
inicial do sistema.
44
Teste
O produto do fluxo de teste o modelo de teste
O modelo de teste pode descrever:
como componentes executveis, provenientes do fluxo de
implementao, so testados.
como aspectos especficos do sistema testados, como por
exemplo, se a interface do usurio til e consistente ou se
o manual do usurio cumpre seu objetivo.
45
Os Artefatos
Cada uma das disciplinas do PU pode gerar um ou mais
artefatos, que devem ser controlados e administrados
corretamente durante o desenvolvimento do sistema.
Artefatos so quaisquer dos documentos produzidos
durante o desenvolvimento, tais como modelos,
diagramas, documentos de especificao de requisitos,
cdigo fonte ou executvel, planos de teste, etc.
46
Os Artefatos
Muitos dos artefatos so opcionais, produzidos de acordo
com as necessidades especficas de cada projeto.
Exemplos:
Diagrama de casos de uso
Diagrama de Classes
Diagrama de Sequncia
Cdigo fonte
Etc.
47
RUP Rational Unified Process
uma instncia especfica e detalhada do Processo
Unificado.
Processo proprietrio de Engenharia de Software criado
pela da RationalSoftware Corporation, adquirida pela
IBM (atualmente IRUP)
Fornece tcnicas a serem seguidas pelos membros da
equipe de desenvolvimento de software com o objetivo
de aumentar a sua produtividade
48
RUP Rational Unified Process
um processo considerado pesado e preferencialmente aplicvel a
grandes projetos.
O fato de ser amplamente customizvel torna possvel que seja
adaptado para projetos de qualquer escala
O RUP , por si s, um produto de software. modular e
automatizado, e toda a sua metodologia apoiada por diversas
ferramentas de desenvolvimento integradas e vendidas pela IBM
atravs de seus "RationalSuites".
49
RUP Rational Unified Process
Princpios e melhores prticas
Gesto e Controle de Mudanas do Software
Gerenciar requisitos
Usar arquiteturas baseada em componentes
Modelar o software visualmente (diagramas)
Verificar a qualidade do software.
50
RUP Caratersticas
Semelhante ao PU:
Baseado em casos de uso
Orientado a arquitetura
Iterativo e incremental
Etc.
51
RUP Fases
Semelhante ao PU:
Concepo
Elaborao
Construo
Transio
52
RUP Disciplinas
Gerencia de Projeto
Modelagem de Negcio
Requisitos
Anlise e Projeto (unio de A/P do PU)
Teste Configurao e gerncia de alteraes
Ambiente
Instalao
53
RUP Artefatos
Conjunto de Gerncia
Conjunto de Requisitos
Conjunto de Projeto
Conjunto de implementao
Conjunto de Instalao
54
RUP Mtodos Concorrentes
Cleanroom (considerado pesado)
E os Metodosgeis (leves) como a Programao
Extrema(XP-ExtremeProgramming), e outros
55
Concluso
56
O PU um processo de desenvolvimento dirigido por
casos de uso, centrado na arquitetura e iterativo e
incremental
composto por 5 fluxos de trabalho
Produz um conjunto de Artefatos
O RUP uma instncia do PU voltado para projetos
mais complexos.

Вам также может понравиться