Académique Documents
Professionnel Documents
Culture Documents
UML-1550
=
=
UNimo
~OOWijG
UII!"!~GE
,OQueéUML?
~ • A UML é uma linguagem para especificar, visualizar,
construir e documentar os artefatos de software.
=
• Contribui para as melhores práticas de engenharia de
software, pois é uma linguagem visual.
:31
• A Unified Modeling Language nasceu em 1994 a
partir da junção de vários métodos (Booch, OOSE e
=
OMT)
• Começou como uma iniciativa particular, mas logo
=
várias empresas importantes (IBM, Microsoft, etc) se
uniram ao esforço de padronização
::li • Padrão OMG (UML 1.1 -1997)
63
=
:li
A UML é uma indicação das melhores práticas de engenharia que se mostraram bem
sucedidas na modelagem de sistemas.
A UML e o Rational Unified Process (RUP) nasceram da junção de vários métodos (Booch,
üüSE [Object-Oriented Software Engineering] - Jacobson, e üMT [Object Modeling Technique]
=
:3
- Rumbaugh, entre outros Fusion, Shlaer-Mellor e Coad-Yourdon), por isso se chama 'linguagem
unificada' e 'processo unificado'.
:li
:w
:iI
:=I
:11
INSTITUTO INFNET - 63
=s
'~
UML-I:55:
<i.
<:l
Definição
I
--'
o
.0«
o
o«
o
::>
o
w
I
W
u,
~
ti:
1. A UML funde os conceitos de Grady Booch,
oa,
rn
James Rumbaugh e Ivar Jacobson.
oo
>
o«
ti:
2. É genérica e flexível. Pode ser aplicada a uma
w
fil
ti:
diversidade de sistemas.
o·
.0«
rn 3. Tem como foco uma linguagem de
s
l
modelagem padronizada e não se preocupa
m
ti:
Õ
rn
o
com a metodologia de desenvolvimento.
• Método = Linguagem (UML) + Processo
rn
o<:l
oI
(RlTP)
64
2) Não existe um nicho específico do mercado que pode ser desenvolvido em UML, não há seleção por
tamanho do programa, pois a UML se adapta a qualquer tipo de sistema.
Um exemplo dessa capacidade foi a adoção de sistemas distribuídos concorrentes como alvo pelos seus 'I:
criadores. Outro exemplo é o mapeamento das atividades de um sistema em tempo real.
Exemplo de como a UML pode ser útil a todas as áreas participantes do desenvolvimento do software: o
programador que terá um documento com a solução para tradução para a linguagem de programação, facilita
o analista no levantamento e entendimento do software, o arquiteto irá desenhar a solução a ser
implementada, o gerente do projeto poderá planejar a divisão do trabalho, o cliente irá validar e entender o
escopo do projeto - todos tiram proveito do uso da UML.
3) A UML tem como foco uma linguagem de modelagem padronizada e não se preocupa com a metodologia
de desenvolvimento (o processo de desenvolvimento em si). Os esforços foram concentrados em um meta
modelo comum (que unifica a semântica) e em uma notação comum e simples.
INSTITUTO INFNET - 64
==
::i
UML-1550
<i..
o
=:i >
...J
o
o«
Versões e Certificações
-.
C>
<I:
o
2Y'
:::l
o
w
>
w
Z
lL
• A versão atual da UML é a
~
::!
li:
oe, • Algumas partes desta especificação ainda
til
oo
<I:
>
estão em discussão.
li:
:::i W
til
W
li:
• Novidades com relação a versão 1.5:
o
o«
til • Classificadores aninhados
~
til
o
>
jjj
li:
• Melhorias na modelagem de comportamento
Õ
til
o • Melhorias no relacionamento entre modelos de
:::::! til
oo
o
comportamento e de estrutura
>
• Certificações oferecidas pela OMG
:!
65
::3
Versões
~ A especificação completa da UML pode ser encontrada no site oficial (http://www.uml.org).
A versão atual (2.1) ainda possui alguns aspectos sob discussão.
::3 Acrescentou diversas novidades como a possibilidade de criação de novos diagramas sob
demanda.
~ Certificações
A OMG oferece três níveis de certificação:
:iI Fundamental
Você pode trabalhar com os elementos UML mais comuns
Você pode criar diagramas UML simples
:11 Você está qualificado para ser membro de uma equipe UML
=
Intermediate
Você pode trabalhar com vários elementos UML
Você pode criar diagramas complexos
:!I Você está qualificado para ser membro sênior de uma equipe UML
Advanced
ci
c
':i
...:oo
o que é Engenharia de Software?
..:
o
::>
c • A Engenharia de Software envolve o gerenciamento de
w
I
W
três "forças":
LL
~
Atividades que
IProces~
-
ao
oQ. precisam ser "'"
r
'"
oc executadas e fases
..:
que precisam ser
> cumpridas
ao
r-
,pesT_
W
'"
W
ao
o
'..:
'"
'"
o
I-
m
ao
Õ
'"
Ferramentas
-
~
o
s'" Responsáveis pela
execução das
r-
o
I
atividades e pelo
Infra-estrutura gerenciamento do --=
68
incluindo tecnologias processo
-r
o processo de desenvolvimento de software envolve o gerenciamento de três
r
características: processos, pessoas e ferramentas.
Os processos precisam ser bem definidos e padronizados e devem se adaptar aos
--
r
processos de negócio da empresa. Um processo deve ser simples o suficiente para ser entendido e
executado sem falhas, mas não deve eliminar atividades vitais que possam comprometê-lo. Além -
disso, a equipe que utiliza o processo precisa ajudar a revisá-lo rotineiramente, depurando-o.
Habilidades, capacitação, criatividade, iniciativa são características que precisam
ser acentuadas nas pessoas que compõem a equipe. O talento pessoal pode ser melhorado
r
continuamente através de treinamento, incentivos e satisfação em participar de projetos bem
sucedidos.
i
-
-=
Cada atividade definida no processo tem uma ou mais pessoas que precisam !:
desempenhá-la. Muitas dessas atividades precisam do suporte de ferramentas de software que
ajudam e aceleram na sua execução. A homologação de ferramentas é uma atividade cíclica que
precisa ser feita rotineiramente a fim de melhorar o processo de desenvolvimento.
r-
INSTITUTO INFNET - 68
:li
=
=
~
-
:<
Engenharia de Software
:::>
~
• "Equilíbrio de Forças"
:li :ii:
--l~~~~~ ~~===;;I//
ãz
...
= ~
Processos Pessoas
!:
i:
r---- Sucesso
..~
=:=11I
>
:: iOS 1----+ Confusão
JII.
JZ
JII.
::
..
:<
!!
Falsos Inícios
:ii: Frustração
~ I
!!
r---- Ansiedade
:li ! L.-_-----J
Lentidão
~
69
==- fatores para cada um dos elementos do desenvolvimento: processos, ferramentas e pessoas.
Na figura acima pode ser visto o que normalmente acontece se uma determinada
:11 características não existe ou não atinge um bom nível de qualidade.
:3
=
=
=::11I
::11I
:11I
:11
INSTITUTO INFNET - 69
~
UML-1550
<i
a
~
o
.« Processos de Desenvolvimento
~
u
:::l
a
w
I
W
-
~
íiiiiiiiiiiii
70
No processo de desenvolvimento podem ser reconhecidas diversas fases que devem ser
cumpridas a fim de que tenhamos o sistema funcionando à disposição do usuário. O processo de
desenvolvimento define a regra do jogo.
Em cada fase do projeto, é necessário executar diversas atividades, tais como: -
.~
INSTITUTO INFNET - 70
.
F~ ·,.Jg;;gg,
:11
UML-1550
:11
<'
!O
:31 --'
~
o Processos de Desenvo!;~e~~oj.o
~~íí)<7..eg--o
<
=-
~
~
E
.u
Z
L.
~
~
• Ciclo de Vida
Tradicional Iterativo (RUP) Extreme Programming
~
:< MU:l"~~$P1
=-:I ..
>
I:
.11
.11
I:
..
;;;:
~
E
~
=-:3
!
71
;li
:11
:11I
;jI
=
INSTITUTO INFNET - 71
UML-1550
<i
c
!:i
o
'00:
o
Rational Unified Process
--.,..-
00:
U
::l
C
w
tiz • Origens
u,
~
o::
oDo
- O RUP foi desenvolvido originalmente na
rn
O
C
Suécia por Ivar Jacobson, sendo batizado, na
00:
>
o::
w
ocasião da sua concepção, de Objectory.
rn
w
o::
o
'00:
- Trata-se de um processo iterativo e incrementaI
rn
rn
O e indica o uso da UNIL.
t::
w
o::
C
rn
- O RUP é um framework, ou seja, você pode
O --.::
rn
O
C
~
adaptá-lo para as suas necessidades.
'~
---- '-
o RUP foi desenvolvido originalmente na Suécia por Ivar Jacobson, sendo batizado, na
ocasião da sua concepção, de Objectory.
'~
Trata-se de um processo iterativo e incremental baseado na UML, cujo foco central são os
modelos de caso de uso e métodos de projeto orientados a objetos.
--=
-
--.
'~
'~
-
E
-
INSTITUTO INFNET - 72
~
::I
UML-1550
=::s
<i
-=:
't>
«
E
::w
i5
,L;
!.LJ
Z
LL.
~
Disciplinas
11:
~ ~
:c
o
Modelagem de Negócios
Requisitos
~
=::I.
>
:: Análise e Design
'"'"x:
'" Implementação
~ Teste
'"
:: Implantação
o
n
:>::
Geren. de
Õ C.Qnf\9ura~o e Mudança
Q
o Gerenciamentó de Projero _ _....!--_.........."'"'-!-- IIIIIIIIiIl~ .......
=t
Q
·0
C
e
Ambiente
::I
73
:t
::I
::J
INSTITUTO INFNET - 73
UML-I55:
-
r
~
~
o
.«
o
~
::::l
C
RUP: Requisitos
[Now SstemaJ [Si si:ema Existentej
-
if
W
[No'J3 Ertra:la]
I
Z
lL
~
~
-
D:
oo. Anaisa- o I~
Ul Problema
oc
« t [Problema
Incorreto]
~
w
[fi
p:
o
.«
Ge-enciar Requisitas
tvt.Jl:á.....as
-
~
-
Ul
[Não posso fazer
Ul
o
!::: --~"i~ijil--<ll
tO~,Q o traJalho)
~
w
D: Definir o Gerendaro Escopo [TnDalhã
Õ Sistema do aatema no sscopo]
-
Ul
o
Ul
oc ~
g
Refina- ~
Definição do Sstema
r
-
74
r
Definir o Sistema (Analista de Sistemas) : realizar uma análise das necessidades dos
envolvidos, refinar a visão do sistema e seus casos de uso.
Gerenciar o Escopo do Sistema (Arquiteto de Software e Analista de Sistemas): priorizar
-
e refinar os requisitos, definir o conjunto de casos de uso mais relevantes, definir o que será
mantido.
Refinar a Definição do Sistema (Especificador de Requisitos, Designer da Interface):
descrever com detalhes os casos de uso, detalhar especificações suplementares, modelar e criar o
-
'ir
visão do usuário.
-
1f
-
~
INSTITUTO INFNET • 74
-
~
~
UML-1550
::I
q;
c
::I ....
.....
o
o«
o
RUP: Análise e Projeto
-c
o
::::l
::I C
W
....
W
Z
lL
:?:
:I
EC
O
O
'"
O
c
-c
>
~
EC
W
'"
w
EC
O
o«
'"
::li '"
O
....
U;
EC
Refinar a
Arquitetura
E
'"O
:I '"Oc
O
Projetar
Co mpcnernes
Projetar o
Banco de Dados
....
=t
75
:.t
Fluxos da Análise e Projeto:
:I Definir uma Sugestão de Arquitetura (Arquiteto de Software, Designer): criar o esboço
inicial da arquitetura do sistema (identificar elementos mais relevantes, definir as camadas),
:=I identificar classes de análise, atualizar casos de uso.
Analisar Comportamento (Arquiteto de Software, Designer, Revisor de Design):
=
~
transformar as definições dos casos de uso em um conjunto de elementos viável para o trabalho de
designo
Projetar Componentes (Designer, Revisor de Design): detalhar elementos de design,
atualizar casos de uso, revisar o design, implementar componentes, testar componentes.
Projetar Banco de Dados (Designer, Designer do Banco de Dados, Revisor): identificar
:I
classes persistentes, projetar estrutura do banco de dados, definir estratégias de armazenamento e
=
recuperação de dados.
Refinar Arquitetura (Arquiteto de Software, Revisor): identificar mecanismos e
elementos de design, descrever arquitetura e distribuição.
:!I
Realizar Síntese Arquitetural (Arquiteto de Software): demonstrar que há solução
arquitetural viável para satisfazer os requisitos do sistema.
:li
:11
:iI
INSTITUTO INFNET - 75
:ti
UML-I550
<i
c
~
o
'<l:
o
<l:
o
=>
c Esirut urar o tIobdelo
UJ de Implementação
lüz t
u,
~
mJ,
Pl:an~ara
a: Integração
~ ,j,
til
o
c
-
<l:
>
a:
UJ
til
~
UJ
~ [Componentes Testados
o em Unidadesdisponíve:is]
'<l: [Mais Componentes
til
til para Implementar
o nessa Iteração]
!:: [Mas
UJ
a: '~:t~~~~a~~ _""I'""'.....a;.,._ _~
Õ
-
essalteraç:ào]
til
o
til
o [Feita)
E
C
~
76
-
E
-
~
Fluxos de Implementação:
-
~
-
E
INSTITUTO INFNET - 76
-
~
= UML-1550
:11I
=- ~
-
<:D
~
RUP: Testes
lEI
=-::- n
z
z
.....
~
E
§:
~
t
Definir Missão
deATiação
g r--~
VerifiGarAbordag em Validar Estabilidade
< do Teste do Build
>
:- E
ll.
'"
ll.
E
:<
I
(Outra
Técnica]
~ t
== Testar e Realizar
:11I c
==
e-
i:
E
::5
Avaliar Missão
Aceitável
t
s. ~'
>Ir
:3 O
c
c
AprimorarVantagEns do Teste
}
=- ~
......
outro Ciclo
de Teste)
= Fluxos de Teste:
:::. Definir Missão de Avaliação (Gerente de Testes, Analista de Testes): identificar
estratégias de testes, descrever métodos de teste e definir formas de avaliação.
:11 Verificar Abordagem do Teste (Gerente de Testes, Analista de Testes, Testadores):
verificar se a abordagem definida funcionará e estabelecer a infra-estrutura.
=::31 Validar Estabilidade do Build (Gerente de Testes, Analista deTestes, Testadores): fazer a
avaliação da estabilidade do build, identificando o build como aprovado ou não.
Testar e Avaliar (Gerente de Testes, Analista de Testes, Testadores): fornecer avaliação
contínua dos itens de teste.
::I
INSTITUTO INFNET - 77
:21
UML-155W
<i.
a
I
....I
O
-o«
RUP: Implantação.
o
U
o« ~:
::> p-i-~-~;J~r
a Implantação
w
I
W
u.
i!E
a:
O Gerendâ~T~·ste de
e,
"' Aoeitação<N,? Local do
'"a
O
üesenvower Material
de Suporte
nesewotv i mento>
o«
>
a:
w
'"a:w
Ó
.0« Produz.ir Unidade
'"'"O de Implantação
!::
w [R etease do
..
Client:l::r::<
[""e•• ê ·""1 ""1eI1
-:-: : : : : : : : : : : :-:-:-: :_-;:
a: 'f Produto de
Õ Teste Beta
'"O [Softv..<are
'"a
O
Descarregával]
O
I
78
~
Fluxos de Implantação:
Planejar Implantação (Gerente): planejar a implantação do software.
Desenvolver Material de Suporte (Autores do Material de Treinamento): escrever o
material que auxiliará no trabalho de implantação do software.
Gerenciar Teste de Implantação (Gerente): garantir a aceitação do software antes do
lançamento geral.
Produzir Unidade de Implantação (Gerente, Implementador): criar uma unidade de
r
implantação (software e recursos de instalação necessários).
Produto de Teste Beta (Gerente): criar um produto de teste para a obtenção de feedback
-
sobre o software.
Gerenciar Teste de Aceitação (Gerente): garantir a aceitação do software antes do
lançamento geral.
Empacotar Produto (Gerente, Artista): reunir as unidades de implantação, scripts de
instalação e manuais para produção do software.
-
r
~
-,-'---------'--
INSTITUTO INFNET - 78
- -
-
ir
•
UML-1550
.;;(
Rational Unified Process
J
<
=:
iI
• o RlTP é uma implementação do modelo de
espiral, no qual as fases se repetem e se
sobrepõem
• Ciclo de Vida:
- Concepção
:ui
li:
- Elaboração
:5
:::
o
::: - Construção
o
:=
o - Transição
79
Desenvolvimento iterativo
Controle de requisitos
Arquitetura de componentes
O RUP foi construído a partir de um ponto de vista de gerenciamento, tendo sido dividido
em quatro fases: concepção (iniciação), elaboração, construção e transição. Estas fases não são
independentes, ou seja, uma não termina necessariamente antes da próxima começar.
Podem ser realizadas várias iterações sendo que em cada uma delas é feito o trabalho das
quatro fases. Cada passagem completa é denominada de ciclo de desenvolvimento.
INSTITUTO INFNET - 79
UML-I550
<i
c
S
o
.C(
Fase de Concepção
~
o
=>
c
w
I
w • Na fase de concepção é estabelecido o contexto de
Z
u,
~
a::
negócio para o sistema e delimitado o escopo do
o
n.
(f)
projeto.
o
cc(
>a::
• O contexto de negócio inclui também um critério de
w
(f)
w
r;<:
sucesso, ponderado em função de recursos e tempo.
o
.C(
(f)
(f)
• Devemos elaborar um cronograma básico de
o
~
w
execução com as principais fases e datas
a::
Õ
(f)
o
• Nessa fase o sistema é descrito através de um texto
(f)
o
c sumário, resumindo o que é o sistema, e de um
o
I
diagrama de Caso de Uso geral, contendo os atores e
as suas principais funcionalidades.
80
-
i!
INSTITUTO INFNET - ao
I=============~~~==---------
•
11
UML-1550
<i.
o
11
-'
o
-o:
Fase de Elaboração
t>
-c
o
5
11
lU
....
OJ
• Consiste de uma análise mais refinada do sistema a
...
Z
'"
l!J
::I:
detalhamento de interações e estrutura do sistema.
o
-o:
et:I • Construir um protótipo que teste a arquitetura
11
CIl
o
....
iü
c::
escolhida.
Õ
et:I
o
• Nessa fase os Casos de Uso são completamente
11 cn
oo
o....
detalhados, são elaborados todos os diagramas de
classes identificadas, são feitos protótipos das telas e
iI o projeto lógico do banco de dados é elaborado.
81
iI
11
!
Consiste de uma análise mais refinada do sistema a ser construído, juntamente com um plano
detalhado de trabalho a ser feito. As metas da fase de elaboração são: analisar o domínio do
problema, estabelecer uma arquitetura funcional, desenvolver um plano do projeto e minimizar
elementos de riscos potenciais ao projeto.
Essa fase envolve a elaboração de um projeto completo, com o detalhamento de interações e
estrutura do sistema. Nessa fase também podemos construir um protótipo que teste a arquitetura
escolhida.
Por exemplo, podemos ter a incumbência de criar uma aplicação para Web usando Java Server
Pages - JSP. Nós vamos detalhar as interações dos atores com cada caso de uso, vamos modelar as
classes do sistema e vamos construir algumas páginas JSP para testar a sua funcionalidade.
Podemos ainda envolver a participação do cliente nesse processo.
,
1
INSTITUTO INFNET • 81
UML-I65:
I
~
I
...J
o Fase de Construção :1
'-C>
o:
i3
::>
"w
I
W
• Trabalhamos sobre o protótipo da fase anterior I
Z
u,
~
adicionando novas funcionalidades e refinando as
a:
oQ.
CJl
o
funcionalidades pré-existentes. I
"-o:
>
• O gerente do projeto define várias versões que
a:
w
CJl
w
devem ser liberadas a cada ciclo.
.a:
o
'-CJl
o
l
cada parte da aplicação.
m
a:
C
CJl
• Nessa fase os módulos do sistema são
o
CJl
o implementados e refinados em ciclos (iterações).
"
~ O projeto físico do banco de dados é
implementado.
82
I
Durante a fase de construção trabalhamos sobre o protótipo da fase anterior adicionando novas
funcionalidades e refinando as funcionalidades pré-existentes. Chamamos essa abordagem de
iterativa (por ciclos) e incremental (adicionando valor).
O gerente do projeto define várias versões que devem ser liberadas a cada ciclo, incluindo
alterações, refinamentos e novas funcionalidades.
A cada ciclo é necessário rever os requisitos de cada parte da aplicação, pois essa é a essência
do desenvolvimento incremental.
INSTITUTO INFNET - 82
I:~
----
:11
UML-1550
:11
<i.
=
::l
:J
c
«
o
Fase de Transição
«
:.J
::::I
:I
::l
:.ll.
iu
z
• Nessa fase o software pode ser instalado em
L
~ ambiente de produção para que os clientes possam
= OI:
~
CO
O
::l
«
>
trabalhar com ele - versão beta.
• A medida em que testes são executados e
=
c:
Lt.!I.
Q
:.tJ.
c: melhorias são implementadas é produzida a versão
O
«Q
final do produto.
:I
Q
2
ii
OI:
Õ
• Nessa fase, além da versão beta e do produto final,
""o são produzidos os manuais e componentes de
:3 ""o
::>
e distribuição do software.
:3
83
:3
Nessa fase o software pode ser instalado em ambiente de produção para que os clientes
:3 possam trabalhar com ele. Como esta transição será feita ? Em paralelo com o sistema atual ou
simplesmente o substituído deixará de funcionar para início do novo sistema ?
:I
Assim que o programa entra em operação, é previsto que alguns pequenos ajustes sejam
necessários para que a versão final esteja disponível.
:3
Um marco dessa fase é a "versão beta" do produto para testes.
Se tiver programado é nesta fase que ocorre o treinamento e outro produto (ou artefato) é o
:I
:I
:i
:t
:i
INSTITUTO INFNET - 83
:=I
UML-1550
::li
~
:11 -
.<:>
Extreme Programming (XP)
~"<"",-,,,~",,,,,,,,,,~"'=--'--''''~''.~~---'--'''~"-'- ,~-" - .,. -
=-:a
<
~
:ii
;
z
~
• Processo ágil de desenvolvimento
~
~
t • Criado por Kent Beck, Ward Cunningham,
u
~
<
>
and Ron Jeffries em 2000
:z::
:I u
;a,
""
:z:: • Objetivo principal: entregar o software que o
....
~
cliente quer no momento em que ele precisa
:11 o
Ü
• Menos formalização e mais disciplina
....
:z::
:i
o
~ c
::l
:::
• Sugere práticas para alcançar valores
~
85
= Processo ágil de desenvolvimento criado por Kent Beck, Ward Cunningham, and Ron
= Jeffries.
Um manifesto (http://agilemanifesto.orgl) foi escrito para descrever o que é o
~ desenvolvimento ágil e porque ele está sendo usado:
"Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e
ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:
~
Indivíduos e interações mais que processos e ferramentas;
Software em funcionamento mais que documentação abrangente;
::11
Colaboração com o cliente mais que negociação de contratos;
:11
:11
:11
INSTITUTO INFNET - 85
=iI
-- - - - -- - - - - - - ---.,----- ---~-----~-----.-_._--------------~.~._._-_._----------_._'---~-- - .-_. -- ------_._---_._----_._,,---~---_._----_.~----_._--
"I
I
I UML-I55:
II
!I
<i
c
~
o
.«
Valores do XP
o
«
o
:::l
C
w
luz
LL
1. Comunicação
~
D:
o
O
Maior comunicação entre membros da equipe 11:
'"
o
c Não é limitada por processos formais
«
>
D:
W
'"w
D:
2. Simplicidade
o
.«
'" Redução da complexidade do sistema
'"o
!:: :~
w
D: Não projetar de maneira genérica
Õ
o'"
'"
o
c
~
86
L.~.-============-===~~~
INSTITUTO INFNET - 86
-
r
:li lIML -1550
:I
e""
:11 ....J
o
<
o
Valores do XP
<
~
s
:I .1C
.L!
%
3. Feedback
.L
;?;
Tanto sobre a qualidade do código quanto sobre
=-
::
~
15'" o seu funcionamento
<
>
3 4. Coragem
J:
.,""
""J:
..< Jogar fora práticas que causam problemas
:li ..c
~
..
:I!:
:5
=-
o
31
-• Feedback. Quanto mais cedo os problemas aparecerem, mais cedo serão resolvidos ou pelo
menos contornados. Estes problemas podem ser de qualquer tipo: no código, processo, interface,
requisitos, etc.
11 Nesta área o XP oferece as práticas que mais fizeram sucesso: feedback sobre o código:
programação em par, testes de unidade (test-first) e posse coletiva; feedback sobre o
desenvolvimento: histórias do cliente, integração contínua, jogo do planejamento.
iiII Ambas as práticas permitem que:
11 As decisões sejam tomadas de forma mais fácil, mais segura e com menos riscos
Estimativas sejam mais precisas
11 Coragem. Todas as práticas vistas até agora, além de terem benefícios próprios, possuem
uma consequência benéfica: o desenvolvedor fica mais confiante e seguro para tomar atitudes que
provavelmente não faria sem o XP:
11 Mexer no código que está funcionando para tomá-lo mais simples.
•
11
Jogar trabalho (código) fora quando for necessário
Mexer no proj eto a qualquer momento
Pedir ajuda
11
INSTITUTO INFNET - 87
a a
:I.
UML-1550
=::J ::'
-
:<c-
Práticas do XP
::I
<
~
ir
:Li:
z
~
~
5. Padrão de Codificação (Coding Standard/)
• Parece que uma pessoa fez todo o sistema
J
::J ~ 6. Posse Coletiva (Collective Ownership)
~
<
> • Todos são responsáveis
>:
::I z.!
'">:
'" 7. Integração Contínua (Continuous Integration)
:<.,
• Várias vezes ao dia
.,
::I 2
E
>:
8. Metáfora (Metaphor)
.,c
Õ
:3
5. Padrão de Codificação (Coding Standard)
::I Definição de padrões para nomes de classes, variáveis, métodos, tabelas, campos,
constantes, estruturas, posição de chaves, identação.
=
~
momento e todos são responsáveis por ele.
7. Integração Contínua (Continuous Integration)
A integração entre as várias partes do código devem ser feitas com muita frequência
para eliminar o mais rápido possível os erros de integração.
8. Metáfora (Metaphor)
:I A comunicação da equipe é importante, portanto todos devem ter uma visão unificada
sobre o sistema. A metáfora é uma analogia com alguma coisa que todos conheçam,
=2 por exemplo: "este software parece um jogo de xadrez" se referindo a um sistema de
simulação financeira.
9. Ritmo Sustentável (Sustainable Pace)
Projetos XP devem ter prazo adequado pois horas extras demais afetam a
produtividade, a comunicação e a disciplina.
:iI
:ti
:11
INSTITUTO INFNET - 89
:iI
UML-J550
<i.
a
:; Práticas do XP
~
O
.«
o
«
O
=>
a
w ,~
f
w
Z
lL
10. Programação em Par (Pair Programming)
~
a:
O
o..
• Troca e alternância
rJl
O
a
«
>
11. Projeto Simples (Simple Design)
a:
w
ffi • Apenas o que é necessário
(Test-Driven~
.a:
O
.«
rJl
rJl
O
12. Orientação a Testes
!::.
w
a:
Õ
• Teste primeiro, programe depois
rJl
O
rJl
O
a
13. Refatoramento (Refactoring)
O
f
• Melhoria contínua do software
90
~ UML-1550
~
<é
Cl
~ !:;
o
-.:
Vantagens
oq:
o
ffi-
-
.•. : :;iI :::l
Cl
w
I
w
Z
LL
• Foco na codificação (programas pequenos)
:i!:
ti:
o11. • Envolvimento do usuário
cn
oCl
-c
>
ti:
• Trabalho em equipe e comunicação
W
cn
W
ti:
o
• Responsabilidade pela qualidade
,q:
cn
cn
o
to
• Simplicidade
w
ti:
Õ
cn
o
• Testes frequentes
sn
oCl
~
• Melhoria contínua
91
~.".'
~
~.'
~
t=i
~
~.
d:,
INSTITUTO INFNET - 91
~
UML-155D
Desvantagens
• Foco na codificação (programas grandes)
• Baixa taxa de reutilização
• Ausência de processo e documentação formais
• Não funciona bem quando:
espalhadas
- O código não puder ser modificado
- A compilação/testes demorarem demais
- Os programadores do par forem experts
92
e gerenciado e até mesmo a quantidade de diferentes tipos de trabalho (o projeto passa a ser muito -=
A reutilização no XP é muito baixa pois não existe documentação e o código não é feito de
maneira genérica.
A taxa de defeitos encontrados quando um programador faz uma revisão na tela é de 10 a
25%. Esta taxa sobe para 20 a 40% quando a programação em par é utilizada. Entretanto,
processos estruturados de revisão de software encontram de 60 a 80% dos erros, reduzindo
bastante o tempo gasto com testes.
e:=
.-...
-
INSTITUTO INFNET - 92
-
tT:9
1,"1
~il
ai a
:I
UML-1550
:s
ei
:B
o
f
...l
o
<I:
o
Processo Sinaples
«
u
~
::3 a
w..JI
f
'U
Z
• Processo usado no curso para a solução dos
~
o:: exercícios, laboratórios e estudos de caso.
:I oo
::o
o
a
-c
>
• Passos:
::I
o::
""'co
",
o::
1. Elaborar documento de visão
o
<I:
co 2. Identificar funcionalidades (requisitos
:=í co
o
f
W
Ir
funcionais)
Õ
::o
o 3. Detalhar funcionalidades
:I co
o
o
oI
:I
93
:3
:iI
INSTITUTO INFNET - 93
=8
._j.\iF~
UML-I550
<i.
c
~
o
'<C
Processo Simples.
o
<C
U
=>
c
...ww • Passos:
Z
LL
õ!:
o:
o 4. Identificar casos de uso
"
li)
o
c
<C
5. Associar telas a casos de uso
>
o:
w
13 6. Detalhar casos de uso
.0:
o
'<C
li)
li)
7. Desenhar o(s) diagrama(s) de casos de uso
o
!::
w
o:
8. Identificar classes de negócio
E
li)
O
li)
O
c
...
O -
.~
94
'Ê
Identificar casos de uso: elaborar uma lista com os casos de uso que farão parte do escopo
do sistema. Dicas:
Imaginar como o usuário final perceberá as funcionalidades do sistema, listadas na "Lista
de Funcionalidades".
Lembrar que casos de uso são macro-funções do sistema perceptíveis pelo usuário - têm
início, meio e fim (o início e o fim são percebidos pelo usuário).
Usar verbos no infinitivo para representar os nomes dos casos de uso.
Lembrar da existência do ator Tempo para processos batch, aqueles que são iniciados pelo
sistema, em horários definidos.
Associar telas a casos de uso: Para facilitar a identificação dos casos de uso é possível
criar a estrutura de navegação de telas (protótipos ou diagramas) e associar telas aos objetivos de
uso dos usuários.
Detalhar casos de uso. Cada caso de uso identificado dever ser descrito de maneira
completa. Todas as interações e exceções devem constar da descrição. Para casos mais complexos
são utilizados diagramas específicos.
Desenhar o(s) diagrama(s) de casos de uso: Desenhar o diagrama de casos de uso,
identificando casos de uso primários e secundários.
Identificar classes de negócio: Identificar as classes (entidades, tipos complexos) que
aparecem nas descrições de casos de uso.
INSTITUTO INFNET - 94
:11
UML-1550
::11
~
Processo Sinaples
= ...c
'"«o
~
= c
:.Li<
.c
...
Z
~
• Passos:
= 9. Identificar relacionamentos
l::
~
:I:
C
~
10. Detalhar as classes de negócio
>
z:
;I
:til.
'"
'L!.
:>:
11. Desenhar diagramas de sequência
C
-o:
'"
12. Identificar estados
:I
'"
c
Ü
:>:
3"
'c"
:3
'"
'o
o
o
!~
;I
95
~
Identificar os relacionamentos das classes: Desenhar o diagrama de classes e identificar
:3
os relacionamentos que existem entre elas.
Detalhar as classes de negócio: Identificar os atributos e métodos das classes. Esta tarefa é
feita simultaneamente com a seguinte.
:I Desenhar diagramas de sequência: Desenhar os diagramas de sequência para descrever os
casos de uso e identificar novos métodos, atributos e classes.
:I Identificar estados: Identificar os possíveis estados de objetos do sistema. Normalmente
um objeto tem estado se sua classe possui algum atributo que indique tal fato. As descrições de
casos de uso e diagramas de sequência também são lugares onde os estados podem ser
:I identificados.
Este processo é feito de maneira iterativa e incremental, assim como o RUP. A cada passo,
:I os diagramas anteriores são revisados para refletirem a nova condição do sistema.
A partir deste estágio, o projeto pode ser iniciado. Nesta etapa as tarefas do desenvolvedor
:I são:
• Projetar Banco de Dados
• Identificar requisitos não funcionais
:I • Relacionar requisitos não funcionais a casos de uso
• Definir arquitetura
:t • Identificar classes de projeto
:I
:J
INSTITUTO INFNET - 95
::J
---- -,--,--,---
:11I
UML-1550
:11I
~
::11
-o
<:;;
Diagramas: Visões do Sistema
o(
=
Q
s
...""
Z
L.
=
~
..'"
o
e,
o
:l
<t
:11
.
:>
li:
.cJ
.IJij
:li:
o
<
'"
:11
SI
...
O,
E
'"
:5
= '"
O
'"
o
::l
...o
A UML integra várias visões do sistema
3
com o usuário no centro do processo
99
= Cada diagrama da UML apresenta uma visão diferente do sistema mas sempre tendo o
!:li
:
,.
êI
s
INSTITUTO INFNET . 99
J
UML-I550
«
o
'"
~
,«
Diagramas Básicos da UML
~
o
::>
'w"
I
Oiagrama
w
Z
lL
Objetos
~
o:: ++
oO
+
++
CIl
+
o
'"
«
>
o::
w
CIl
w
.0::
o
.«
CIl
CIl
o Diagrama de
!::
w
o:: Componentes
;:,
CIl
o
CIl
o
'"
o
I
100
A figura acima mostra os diagramas mais utilizados nos projetos UML. Os cinco diagramas
em destaque serão estudados neste curso e são os mais importantes para a análise de um sistema.
:2
ci
c
,...
~ ...J
o
-:o:
Fases X Diagramas _
o
<l:
U
:::>
::I '"
t:J:
,...
z""
Captura de Requisitos Análise e Projeto Construção
- -
u,
:!::
o::
:li o
a,
oc'"
<:(
>
::w
li: Atividades
Atividades
er (fluxo de trabalho,
(comportamento objeto,
'"
'" casos de uso)
AlgOrItmo,operação)
-
li:
o
«
::a
'",...o
'"
Ui
a:
Õ
'"o
:I
'"o
Cl
...o
= 101
=
~
Não existe regra fixa para a utilização de um diagrama em urna ou outra etapa do
desenvolvimento, entretanto a experiência e o bom senso indicam quando estes diagramas devem
ser criados.
=: Os casos de uso são desenvolvidos durante a fase de captura de requisitos. Casos de uso
complexos e fluxos de trabalho podem ser descritos por diagramas de atividades.
No momento da elaboração da solução os diagramas de classes definem a estrutura do
sistema e os diagramas de atividades descrevem métodos ou trechos de métodos. O diagrama de
estados modela as possíveis situações vivenciadas por um objeto, e os diagramas de sequência e
: comunicação mostram corno os atores interagem com o sistema e corno os objetos trocam
mensagens entre si.
:I
Na construção, é necessário definir os componentes de software, ou seja, corno as classes
serão reunidas em unidades de software. Além disso, deve-se definir em quais estas partes serão
instaladas.
:I
:I
:I
:I
:i
:s
INSTITUTO INFNET -101
UML -155oD
oi
a
:;
O
'<l:
Exemplo de uso da UML
o
<l:
U
'"
a
LU
tüz
u,
• Cenário de uma Aplicação
~
te
O
C.
- Este cenário apresenta oito diagramas UML
cn
O
a utilizados na modelagem de um sistema de
<l:
6:LU
cn
software para uma locadora de veículos.
LU
te
. O
'<l:
- Tem como objetivo apresentar uma visão geral do
cn
cn
O
!::
uso da UML na modelagem de sistemas.
LU
te
Õ
cn
O
cn
O
a
O
.....
102
'li a
== UML-1550
=:=li ~
-
<
::;:lo
~
:li ã
:;;:
Z
=-
JL.
;;
!:
L
!!: cliente
=-
<
>
li:
JlI.
'a
~tirar car~
JlI.
li:
<
:a llIt
!
:li:
~
.>:
~
~ llIt
9
= 103
:I
Especifica uma interação entre um usuário e o sistema, no qual o usuário tem um objetivo
:11
muito claro a atingir.
Os usuários são conhecidos como atores e podem ser pessoas, equipamentos, outros
~ sistemas e até mesmo o tempo (quando a tarefa é executada periodicamente de forma automática).
O diagrama de casos de uso fornece uma visão geral do escopo do sistema. Cada caso de
::I
uso deve ser descrito com detalhes. As descrições de casos de uso são a base do restante do
sistema, a partir dele se criam classes, diagramas de sequência, estados, etc.
No sistema da locadora, existem dois atores: cliente e atendente pois ambos usam o sistema
:11
para realizar tarefas diferentes:
O cliente faz a reserva de um carro;
:11 O atendente registra a retirada do carro;
O atendente registra a devolução do carro.
:li
:li
=
=
:ti
= INSTITUTO INFNET· 103
lia
UML-1550
oi
c
~
o
-..:
Diagrama de Classes.
o
<[
u Carro Aluguel
:>
c -placa -dataAluQuel
!.LI
> -mode Lo f---~o-,,·---1-daLaElltrada
!.LI »chas s í
Z 1,,*
u, -e e c edc
~ -preco
li:
O .... -t-r eae rver ()
e,
+retirar ()
"'
O
o
Aqência
-endereco
+devo 1ver () Cliente
<[
> -fone <nome
li: -endereco
w -gerente
Funcionario -fone
"'
!.LI
li: -habilitacao
O »emet.j.
ê1i
"'
O
!:::
!.LI
li:
ã
"O'
"'c
o
O
>
104
- - ~ ~ - ~ ~ -- - - - ~
:11
UML-ISSO
=:JI
~
~
c
/
A
equencia
<:
IJ
<:
g
:11
i:
i:
...
z
~
:li:
"oo"
«
>
T~------------------------.--~lJ
~ 3 : Iist., de carros ~
~O
::
:3
e,
'"
LI
'"O
4 : carro e perfodoO
~O, 5; calcularAluguel()
<xcreece> ,
<:
i
=:3
6 ; dados pessoasf) 7
'"
'O"
f- 9 : verificarl-tlstoríco() :
i:]
II:
Õ
ee
li
O 10 : efetuarReserva()
K-----------------:-------
'"
O
O
[ 11 ; ccnbrmeçêo
O
i
3
:I
=
Mostra uma interação de um ator com o sistema, organizada em forma de uma seqüência,
dentro de um determinado período de tempo. É um dos diagramas de interação.
Os participantes são os objetos (classes), atores métodos.
= A figura acima apresenta um diagrama de sequência que descreve o caso de uso "Reservar
Carro". Nele podem ser encontradas as classes do diagrama de classes e um elemento novo: a
: Fronteira. Este objeto representa a interação com o usuário e serve para abstrair os detalhes de
implementação e focar apenas na parte do negócio, a mais importante da fase de entendimento do
sistema.
:3
:3
:3
:J
:3
:i
:i
INSTITUTO INFNET -10S
:ii
UML-I550
:1:
E:
<i
o
!:J
..o.:
o Diagrama de Comunicação ~
..:
o
::::l
o
w
tu
z
IL 1: Solicitação de Carro
r=
:i!: 3: Informa Reserva (data,carro) 2: BuscaCarro( )
I:
li:
o 5: Identificação Pessoal 4: Calcula Aluguel( )
Q.
sn
o
o
..:
> ~
-~
IFronteira
I
I
I
-~ ---1 ~~~~ I
11:
~v~~,~t'I";OOI
li:
w
<Jl
W
: Cliente
li:
8: Cadastra eserva()
...:o
<Jl J
;/ ~
<Jl
~
m
li:
C
in
o
in
o
o
I: Aluguel I I : Client~=1
~ I I <E-
7: VerificaHistorico( )
106
-
'~
oi.
c
~
o
'<C
Diagrama de Comunicação
to>
<C
o
::>
c
w
I
W
u, 1: Solicitação de Carro
~ 3: Informa Reserva (data.carro) 2: BuscaCarro( )
a:
oa. 5: Identificação Pessoal 4: Calcula Aluguel( )
CIl
o ~ rFr~ ~ ~~car~~1
c
<C
>
a:
W
I r
CIl
: Cliente
w
cad/~:erva( ) 6~aHistoriCO( )
a:
o 8:
'<C
CIl
~-
CIl
o
ina:
15 //
p~ CI~ie_nt_e
CIl
o
CIl
o \
c II _ _
: __
~ -E-
7: VerificaHistorico( )
106
11:
:3
<
Diagrama de Máquina de Estados
::::t
:l :::i
o
...:
'-"
<l:
::;
::>
:J ::::t
L;
~
~
~
::!
ii:
O
"
'"
O
c
« ~--__ Cancelar Reserva.--------L----.
>
Reservado Disponível
:! '"
I!!!J
'"
~
!!:
O
'<l:
'"
:! '"
,O
>
i:i
!i:
Retira Carro
Retir arro
:! '"
O
'"g
~ _ _~Em Manutenção
-• 107
- •
Este diagrama é bem conhecido e utilizado há bastante tempo. Ele mapeia diferentes
:i estados em que se encontram os objetos. Desencadeia eventos que levam os objetos a se
encontrarem em determinado estado em um dado momento.
:3 A figura acima mostra uma visão dos possíveis estados de um objeto da classe Carro
durante sua existência.
:iI
:i
:iI
:Jj,
INSTITUTO INFNET -107
:iI
J
UML-I~'
1I
li
•
<i.
c
!:;
o
'-o:
Diagrama de Atividades
00
-o:
O
::>
C
UJ
l;j
Z
u,
~
a: Veriflcar Histórico do Cliente
O
o..
<Jl
O
C
-o:
>
a:
UJ
fna: Obter I~ormações Pes50ai~ ~ ~ :>- ~~ Rejeitar Cliente
O [ ok] [ há problema,]
'-o:
rJ)
<Jl
O
!:::
UJ
a:
Õ
rJ)
O Confirmar ~e3erva ~ ~.,
<Jl
O
C
g
108
-r
É semelhante ao antigo fluxograma mas possui símbolos para representar outras situações
como paralelismo e objetos.
Apresenta a lógica de algum processo, caso de uso, método ou até mesmo a navegação de
telas de um sistema.
A figura acima mostra a verificação do histórico do cliente. Ele é mais usado para indicar
-r
este tipo de lógica do que o diagrama de sequência pois este normaimente indica apenas o fluxo
normal de execução.
É um dos diagramas mais versáteis podendo ser usado em qualquer situação onde seja
necessário descrever o fluxo de execução de uma atividade.
-
~
-
f
-
E
=:3 <i.
c
>
....I
o Diagrama de Componentes
o«
o
«
o
::>
:I ...c
...z>
"
~
r---------- I
ti:
::I o I
g
I
" I
co
o
'"
«
>
SistemaWEB.DLL -----1
:x: I
:I
I 1
ur
co I
I
I
I
1!l
~'''ml
ti:
o
>«
'"
'"o
:JI >
W
ti:
I
I
C I
I
'"
~
o
~ '"
o
o
o
>
:I
109
:!
Mostra como os diferentes subsistemas de software formam a estrutura total de um sistema.
::I As dependências entre os diversos componentes também são mostradas neste diagrama.
:I
:i
:!
~
::I
::!
:i
es
::2
!I
I
i UML-I55:
I
<i.
Diagrama de Implantação
Cl
~
o
.C(
I
oc(
o
=>
Cl
6
Z
LL
~
tE: P' , 'OO A5 P --- --------~
,,
oD
,,
, ,,
CIJ
oCl ,r-------- ,
g
c(
~ Servidorde Negpcios
w
CIJ
w
tE:
O
O SíslemaWEB.DLL ~----I
,,
5"'''''".DLL I
'0
.C(
,,
,
r--------------- I
g
CIJ
CIJ
o
...m Bencceenerícc.Du, I
tE:
15 ,,
CIJ
o
, i
•
CIJ
oCl Servidorde Banco de Dados
...
o
êf:j
i
110
sistema.
O nome original deste diagrama é "Deployment Diagram". Como não existe tradução
exata, ele tem vários nomes em português: implantação, distribuição e instalação.
'.
i
i•
i•
i
•
i
•
i•
.
i
INSTITUTO INFNET ·110
i
•
::iI UML-1550
::11
~
o
:iI f
....I
o
-o:
o
Conclusão da UA.2
<l:
o
:::>
:11 D
W
l-
w
Z
- A UML não tem uma metodologia embutida,
IL
t:
a:
permitindo que o desenvolvedor use os
::!I oc..
<fl
oo
diagramas como bem entender.
<l:
>
a:
- Cada diagrama da UML mostra uma "visão" do
:3 w
<fl
W
a:
O'
sistema. Nenhum diagrama permite ter a idéia
-o:
<fl
<fl
O
desenvolvimento de sistemas que usa a UML
:!I <fl
o
o
l-
como notação.
:3
111
:3
:!I
:3
:3
=
=
:3
:11
:3
:I
INSTITUTO INFNET - 111
:21
,X.tA _
UML-I55J
<i
c
~
o
.<t
Práticas do XP
o
<t
U
::J
C
W
I
W
Z
u,
1. A Equipe (Whole Tearn)
~
c:
o
D.
o
C
<t 2. Testes de Usuário (Customer Tests)
~
w
Ul
W
c:
• Elaborados pelo cliente
o
.<t
Ul
:g 3. Versões Pequenas (Smal1 Releases)
t:
w
c:
Õ
• A cada versão o software é funcional
4. Jogo do Planejamento (Planning Game) ~J'"
Ul
o
Ul
oc
~ ~/~~r;\ffl
o
I
• Estimativas e prioridades
J.2 fJtr0 {Jft.<J LÁA
88
INSTITUTO INFNET - B8