Vous êtes sur la page 1sur 44

:11I

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

=­ A Unified Modeling Language é uma notação que normatiza um conjunto de diagramas. É


:li uma linguagem para especificar, visualizar, construir e documentar os artefatos de software e
também para a modelagem de negócios.

: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

--'
o
.0«


o
::>
o
w

W

• Definição em Três Partes


Z

u,
~
ti:
1. A UML funde os conceitos de Grady Booch,
oa,
rn
James Rumbaugh e Ivar Jacobson.
oo
>

ti:
2. É genérica e flexível. Pode ser aplicada a uma
w
fil
ti:
diversidade de sistemas.

.0«
rn 3. Tem como foco uma linguagem de
s

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

Definição em Três Partes


1) A UML funde os conceitos de Grady Booch (Método Booch), James Rumbaugh (OMT - Object Modeling
Technique) e Ivar Jacobson (OOSE - Object Oriented Software Engineering).
O resultado é uma única linguagem de modelagem comum e amplamente adotada pelos usuários desses e de
outros métodos.
, t=
Booch é arquiteto de software e já trabalhou em vários projetos complexos difundindo os conceitos de 00,
além de ter escrito vários livros e artigos técnicos.
Jacobson é criador do Objectory (método de desenvolvimento de sistemas) deu importância ao reuso de
software e também é autor de vários livros técnicos.

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

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

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

:11 Você pode trabalhar com todos os elementos UML


Você pode criar diagramas extremamente complexos
Você está qualificado para ser gerente de uma equipe UML
:iI
:iI
INSTITUTO INFNET - 65
ai
================-===-===-====--===-----------­
UML-I550
-r...

ci
c
':i
...:oo­
o que é Engenharia de Software?
..:
o
::>
c • A Engenharia de Software envolve o gerenciamento de

w

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

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

=­ Para que a construção de um software seja bem-sucedido é necessária a existência de

==- 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

W

• Os processos de desenvolvimento são


u,
;;l;
a:
compostos por diversas fases;
o<>.
l/l
o
a
«
• Em cada fase é necessário executar diversas
>
a:
w
l/l
W
atividades.
lI:
o

CIl
l/l
• Esse esforço tem como alvo principal a
o

m
a: construção de um sistema de qualidade.
Õ
l/l
o
l/l
o
a
oI­

-
~

í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: -

• Reuniões com os usuários para definição de escopo e validação do trabalho,


• Gerar documentações (cronograma, documento de visão, diagramas, documentação do
projeto, do programa, etc),
• Fazer protótipos de programas para testar tecnologia, arquitetura ou interação com o
usuário,
• Testar funcionalidades,
• Fazer instalações de computadores, sistemas operacionais, software de apoio ao
desenvolvimento como ferramentas case, compiladores, servidores, etc ..
Todo esse esforço tem como alvo principal a construção de um sistema de qualidade que seja
duradouro, suportando modificações com um mínimo de trabalho.
-

.~

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

:a A forma usual de divisão do processo de desenvolvimento em fases é considerar que o


problema deve ser entendido (análise), projetado (projeto), implementado (construção) e testado
(testes).
:iI A figura acima mostra como três processos diferentes tratam essa questão:
• As formas tradicionais consideram que o usuário deve saber todas as suas necessidades no
:11 começo do processo e que mudanças não irão ocorrer durante o desenvolvimento.
• Os processos iterativos, como o Rational Unified Process (RUP), consideram que
:11 mudanças ocorrem e devem ser incorporadas ao software durante o seu desenvolvimento.
Utilizam o processo iterativo (repetições das fases) e incremental (melhorias no projeto em
cada iteração).
:11 • O processo extreme programming (XP) leva a dinâmica do desenvolvimento ao extremo:
os requisitos mudam muito rápido e devem ser implementados o mais cedo possível para
:11I
que o produto seja útil ao usuário final.

:11

:11I
;jI


INSTITUTO INFNET - 71
UML-1550

<i
c
!:i
o
'00:

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

-ec Rational Unified Process

-=:
'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

Descrição em Duas Dimensões


:I

Esta figura representa duas dimensões:

=­ • A horizontal que representa o aspecto dinâmico do processo, como é ordenado e expresso


em termos de ciclos e marcos de projeto - é o eixo do tempo.
• A segunda dimensão, vertical, representa o aspecto estático dQS processo, como é descrito
::I em termos de atividades, fluxos de trabalho, artefatos e pessoas - é o eixo de conteúdo.
O final de cada iteração é marcado pela entrega de um artefato de software (uma versão, um
::I módulo, um conjunto de diagramas), esta entrega pode ser para validação com o usuário ou para
teste da equipe.
:t Podemos observar que o compromisso de desenvolver um sistema, envolve diversas atividades
que são executadas continuamente durante todo o projeto.
::I No RUP as atividades têm uma alocação maior em função da fase em que se encontra o
projeto. As fases ajudam o gerente do projeto a fazer a apropriação de profissionais e custos,
resultando em uma maior eficiência.
::I
Por exemplo, na fase de Concepção (Inception) existe uma alocação maior de analistas
envolvidos na atividade de "Levantamento de Dados", representada no diagrama por "Business
:ti Modeling" e "Requirements".

::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]

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

A figura acima mostra os fluxos de trabalho envolvidos na etapa onde acontece a


identificação de requisitos. Segue abaixo a lista dos fluxos, seus objetivos e responsáveis pelo
trabalho:
-
1f

Analisar o Problema (Analista de Sistemas): definir as fronteiras do sistema, restrições e


envolvidos.
Compreender as Necessidades dos Envolvidos (Analista de Sistemas): levantar
informações dos envolvidos no sistema para compreender as suas reais necessidades. -
f

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

protótipo da interface do usuário.


Gerenciar Requisitos Mutáveis (Analista de Sistemas, Revisor de Requisitos): avaliar
solicitações de mudança, estruturar os casos de uso, verificar se o trabalho está de acordo com a
-
~

visão do usuário.

-
1f

-
~

INSTITUTO INFNET • 74

-
~
~
UML-1550

::I

q;
c
::I ....
.....
o


RUP: Análise e Projeto
-c
o
::::l

::I C
W
....
W
Z
lL
:?:

:I
EC
O

'"
O
c
-c
>

~
EC
W

'"
w
EC
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:

<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:

Estruturar o Modelo de Implementação (Arquiteto de Software): organizar o modelo de

implementação com o objetivo de minimizar conflitos.


-
E

Planejar a Integração: planejar a construção e ordem de integração dos subsistemas.


Implementar os Componentes (Implementador, Revisor, Integrador): programar os
componentes definidos. E
....
Integrar cada Subsistema e Sistema (Integrador): integração dos novos componentes e
geração de versões do software. . j f[. / 1', /

~ (svl~r:~ ~ Af~f&rP!' él9U<. <=>d'--o <fQ ,4c::y\.{;J~N'")


o~(~Wt}~ -
E

-
~

-
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.

=­ Realizar Missão Aceitável (Gerente de Testes, Analista de Testes, Testadores): defender a


qualidade adequada e identificar regressões de qualidade.
Aprimorar as Vantagens de Teste (Gerente de Testes, Analista de Testes, Testadores):
~ montar scripts de teste, manter configurações do ambiente de teste, explorar oportunidades para
melhoria da produtividade, documentar lições aprendidas.
:s
=­::J

::I

INSTITUTO INFNET - 77

:21
UML-155W

<i.
a

....I
O
-o«
RUP: Implantação.
o
U
o« ~:
::> p-i-~-~;J~r
a Implantação
w

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>


>
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

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

Fornecer Acesso ao Site de Download (Gerente): disponibilizar o produto para download.

­
~

-,-'---------'--
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

o RUP é baseado nos princípios de desenvolvimento de software:

Desenvolvimento iterativo

Controle de requisitos

Arquitetura de componentes

Modelagem visual de software

Controle da qualidade do software

Controle das mudanças no software

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

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

diagrama de Caso de Uso geral, contendo os atores e
as suas principais funcionalidades.
80

Na fase de concepção é estabelecido o contexto de negócio para o sistema e delimitado o


escopo do projeto. Para tal, identificamos os atores que estarão interagindo com o sistema, bem
como os casos de uso associados às essas interações.
O contexto de negócio inclui também um critério de sucesso, ponderado em função de
recursos e tempo. Essa ponderação nos dá o grau de "risco" que é possível assumir.
Além disso, devemos nessa fase elaborar um estudo que tem como produto final um
'I:
cronograma básico de execução com as principais fases e datas de entrega.
Essa fase envolve a elaboração de um ante-projeto do sistema (uma proposta) composto pelo
memorial do projeto, escopo pretendido, principais atores envolvidos, principais casos de uso e o
uma estimativa de cronograma (com os principais marcos do projeto).

-
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

~ ser construído, juntamente com um plano detalhado


li
::I:
o
"­ de trabalho a ser feito.
'"
o
c
-c
> • Elaboração de um projeto completo, com o
11
I:C
l!J

'"
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
....

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
~

...J
o Fase de Construção :1
'-C>
o:
i3
::>
"w

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: • A cada ciclo é necessário rever os requisitos de


CJl

o

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
«

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

=­ conjunto de manuais com instruções de uso do sistema.


Ao [mal dessa fase teremos o produto em sua versão final para uso irrestrito por todo o
:I público-alvo.

: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;

:li Responder a mudanças mais que seguir um plano.


Ou seja, mesmo dando valor aos itens àdireita, valorizamos mais os itens à esquerda."
:I
~

:11
:11

:11

INSTITUTO INFNET - 85
=iI
-- - - - -- - - - - - - ---.,----- ---~-----~-----.-_._--------------~.~._._-_._----------_._'---~-- - .-_. -- ­ ------_._---_._----_._,,---~---_._----_.~----_._--
"I
I
I UML-I55:
II
!I

<i
c
~
o

Valores do XP

«
o
:::l
C
w
luz
LL
1. Comunicação
~
D:
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

o XP tem o objetivo principal de entregar o software que o cliente precisa no momento em


que ele precisa. Para atingir este objetivo quatro valores devem ser incorporados no processo:
Comunicação. Quanto mais eficiente for a comunicação e mais cedo ela ocorrer, mais
problemas virão a tona e poderão ser gerenciados antes que causem maiores estragos. A melhoria
da comunicação entre os membros da equipe pode ser alcançada com práticas simples: A
comunicação não pode ser limitada pela burocracia. Deve-se utilizar o melhor meio possível no
momento: conversa, email, telefonema. A comunicação deve conter o que for necessário para a
explicação: código fonte, diagramas, descrição de casos de uso, etc.
Algumas constatações sobre comunicação: presença física é melhor que telefonema que é
melhor que email. Código simples de entender é melhor do que documentação escrita.
Simplicidade. Manter tudo o mais simples possível toma o sistema mais fácil de alterar,
mais rápido de desenvolver e menos propenso a erros. As práticas XP que reduzem a
complexidade são: a solução (projeto, algoritmos, tecnologia, ténicas) sempre deve ser a mais
simples possível e que atenda as necessidades do cliente. Não há momento fixo para simplificar o
projeto, código ou processo. Qualquer tipo de trabalho que seja feito genericamente
(contemplando possíveis questões futuras) deve ser eliminado.
-
r

L.~.-============-===~~~
INSTITUTO INFNET - 86

-
r
:li lIML -1550

:I

e""
:11 ....J
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 Erros sejam detectados e corrigidos imediatamente


Requisitos e prazos sejam revistos mais cedo, minimizando o custo de alterações

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
Õ

• Analogia para facilitar o desenvolvimento


.,
~ ~
E
9. Ritmo Sustentável (Sustainable Pace)
• Prazos adequados
:I
89

: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.

::I 6. Posse Coletiva (Collective Ownership)


O dono do código é a equipe. Qualquer um pode melhorar o projeto a qualquer


~
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
=>
a
w ,~

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

• Melhoria contínua do software

90

10. Programação em Par (Pair Programming)


A atividade do programador exige conhecimento, concentração, raciocíno apurado,
entre outras características. A programação em par procura maximizar estas
habilidades colocando dois programadores no mesmo computador. Enquanto um fica
com o controle do teclado o outro observa, opina e revisa o código. Estas posições são
'I

alternadas constantemente e quando possível os pares são trocados. Pesquisas indicam


que o tempo que se leva para fazer um programa em par é aproximadamente igual ao I

de um programador sozinho mas a qualidade do código melhora significativamente.


11. Projeto Simples (Simple Design) ,I
O projeto deve se manter simples durante todo o processo de desenvolvimento.
Características que não sejam necessárias para a iteração corrente (versão) não são
implementadas ou projetadas. I
12. Orientação a Testes (Test-Driven)
Os testes são desenvolvidos antes da programação iniciar. Os testes são automáticos e I
executados constantemente.
13. Refatoramento (Refactoring) I
O projeto e o código são refinados continuamente. Antes de uma mudança o código é
melhorado sem que se altere sua funcionalidade. Para que esta prática funcione, a
existência de testes automáticos é imprescindível.
I
I
I
INSTITUTO INFNET - 90
I

~ UML-1550

~

Cl

~ !:;
o
-.:
Vantagens
o­q:
o
ffi-
-
.•. : :;iI :::l
Cl
w

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

As vantagens do XP já foram enumeradas nas páginas anteriores: basicamente as práticas


resolvem vários problemas no desenvolvimento de software (apesar de criarem outros como será
visto a seguir).
O foco na codificação diminui a quantidade e necessidade de projetos e documentação.
Deve-se salientar que esta vantagem existe apenas para projetos pequenos.
O envolvimento do usuário na equipe permite que problemas sejam descobertos mais cedo
facilitando o acompanhamento dos trabalhos e aumentando a confiança de todos no sucesso do
empreendimento.
t=I Equipes unidas que se comuniquem facilmente, a existência de padrões de documentação e
da possibilidade de se alterar o software a qualquer momento faz com que todos sejam
~ responsáveis pelo sistema.
Simplicidade, testes frequentes e melhoria contínua facilitam a manutenção e a qualidade
t:3
do software.

~.".'
~

~.'
~

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:

- A comunicação é difícil: equipes grandes ou

espalhadas
- O código não puder ser modificado
- A compilação/testes demorarem demais
- Os programadores do par forem experts

92

A principal desvantagem do XP aparece quando o software aumenta de complexidade pois


aumenta também o número de pessoas envolvidas, quantidade de código que deve ser programado e-­

e gerenciado e até mesmo a quantidade de diferentes tipos de trabalho (o projeto passa a ser muito -=

mais do que apenas um projeto de software). F:-~


u : .

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:=

A falta de planejamento de qualidade (métricas e gerenciamento de qualidade) exige muito ~

tempo de teste. O desenvolvimento pode chegar a um ponto bem semelhante a um processo de


tentativa e erro.
Nem todos os requisitos podem ser tratados com a abordagem do XP. Requisitos não
ce=

funcionais restritivos que limitam a funcionalidade do sistema (desempenho, disponibilidade,


segurança, etc) não são suportados pelo XP.
==

.-...
­-
INSTITUTO INFNET - 92
-

tT:9
1,"1
~il

ai a
:I
UML-1550

:s­
ei

:B
o

...l
o
<I:

Processo Sinaples
«
u
~

::3 a
w..JI

'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

W
Ir
funcionais)
Õ
::o
o 3. Detalhar funcionalidades
:I co
o
o
oI­

:I

93

:3

Os processos de desenvolvimento são apenas diretrizes e sugestões sobre como projetar


:11 sistemas. O próprio RUP é um framework que deve ser adaptado de acordo com a realidade de
cada empresa.
Será apresentado agora um processo simples que utiliza algumas técnicas conhecidas e
:3 partes de outras metodologias. O objetivo deste processo é servir de base para que o aluno consiga
elaborar seus primeiros sistemas e até mesmo definir seu próprio processo.
:3 A primeira parte é a análise e projeto inicial do sistema:
Elaborar documento de visão: Documento que conta a história do sistema.Ele deve
::3 descrever o sistema de forma natural, conforme o cliente o relata. Se necessário pode-se aplicar
um questionário a fim de colher as informações, visando o "O QUE" o sistema deve fazer, suas
características principais e funcionalidades pretendidas. Deve-se evitar entrar no detalhe do
:B "COMO" o sistema será desenvolvido.
Identificar Funcionalidades (Requisitos Funcionais): As funcionalidades estão
relacionadas com entrada de dados, inclusão, exclusão, atualização, consulta, cálculo,
::3
processamento etc. A lista de funcionalidades serve como um lembrete para facilitar o
detalhamento dos casos de uso. Dicas para criação da lista: 1) Usar verbos no infinitivo para
::3
descrever as funcionalidades. 2) Agrupar os requisitos conforme as funcionalidades sempre que
possível. 3) Colocar em destaque (vermelho) as alterações que possam ocorrer no documento de
visão em função da lista de requisitos.
:i Detalhar funcionalidades: Escrever de maneira bem resumida os passos que devem ser
seguidos (sistema e usuários) para executar a funcionalidade. Neste ponto normalmente são
:ii encontradas subtarefas comuns a várias funcionalidades.

:iI
INSTITUTO INFNET - 93
=8
._j.\iF~
UML-I550

<i.
c
~
o
'<C
Processo Simples.

<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

=­ usuário no centro do processo.


São definidos dois tipos de diagramas:
3
Estrutura
Mostram as partes do sistema de forma estática, sem informações sobre o funcionamento.

=­:iI São os diagramas: classes, objetos, componentes, distribuição, pacotes e estrutura


composta.
Comportamento
Mostram o comportamento do sistema, suas funcionalidades gerais, específicas, como
:­ interage com o usuário, como se comporta com relação ao tempo. São os diagramas:
casos de uso, estados e atividades e os diagramas de interação: sequência, comunicação,

:­ temporal e visão geral de interação

!:li

,.

êI

s
INSTITUTO INFNET . 99
J
UML-I550

«
o
'"
~

Diagramas Básicos da UML
~
o
::>
'w"

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

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.

INSTITUTO INFNET - 100


::I
UML-1550

:2

ci
c
,...
~ ...J
o
-:o:
Fases X Diagramas _


<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

<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

INSTITUTO INFNET -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

A próxima tarefa é a classificação das entidades envolvidas neste processo e o seu


relacionamento.
Diagramas de classe mostram a estrutura geral do sistema e também as suas propriedades
rel acionais e de comportamento.
A locadora pode ser implementada com as classes: Carro, Aluguel, Cliente, Agência,
Funcionário, Vendedor e Mecânico.
O diagrama da figura acima mostra as classes de negócio, aquelas que implementam os
requisitos funcionais da aplicação.
Podem ser feitos outros diagramas de classes com objetivos diferentes, por exemplo, um
diagrama de projeto que mostre as classes ligadas ao controle e à apresentação dos dados para o
usuário.

INSTITUTO INFNET -104

- - ~ ~ - ~ ~ -- - - - ~
:11
UML-ISSO

=­:JI
~
~
c
/
A

equencia
<:
IJ
<:
g
:11
i:
i:
...
z
~
:li:

~ ~ 1 : Soliclação do Carro() . 2 : buscarCarrosO :

"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

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

É um diagrama que possui a mesma semântica (conteúdo) do diagrama de sequência, ou


seja, um pode ser convertido no outro sem perda de significado. O diagrama de comunicação
também é um diagrama de interação.
Ele mostra como um grupo de objetos num caso de uso interage com os demais.
Cada mensagem é numerada para documentar a ordem na qual ela ocorre.
Em versões anteriores da UML, era conhecido como Diagrama de Colaboração.
O diagrama acima descreve o caso de uso "Reservar Carro" do ponto de vista da troca de
mensagens entre os objetos. Compare este diagrama com o anterior e perceba que ambos tem o
mesmo conteúdo. Entretanto, é mais fácil entender a ordem de funcionamento no diagrama de
sequência e mais fácil de visualizar as trocas de mensagens entre os objetos no diagrama de
comunicação. -
~

-
'~

INSTITUTO INFNET -106


UML-I550

oi.
c
~
o
'<C
Diagrama de Comunicação
to>
<C
o
::>
c
w

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

É um diagrama que possui a mesma semântica (conteúdo) do diagrama de sequência, ou


seja, um pode ser convertido no outro sem perda de significado. O diagrama de comunicação
também é um diagrama de interação.
Ele mostra como um grupo de objetos num caso de uso interage com os demais.
Cada mensagem é numerada para documentar a ordem na qual ela ocorre.
Em versões anteriores da UML, era conhecido como Diagrama de Colaboração.
O diagrama acima descreve o caso de uso "Reservar Carro" do ponto de vista da troca de
mensagens entre os objetos. Compare este diagrama com o anterior e perceba que ambos tem o
mesmo conteúdo. Entretanto, é mais fácil entender a ordem de funcionamento no diagrama de
sequência e mais fácil de visualizar as trocas de mensagens entre os objetos no diagrama de
comunicação.

11:

INSTITUTO INFNET - 106


~
UML-1550

: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

[ carro ok] [ > 1 ano ou >15000 krn ]


ã
'"
,O

:! '"
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.

:3 Quando um carro é criado ele está disponível para aluguel.


Se um cliente reservá-lo ele ficará reservado até que a reserva seja cancelada ou até que o
cliente retire o carro. Neste caso ele estará alugado. Ele também pode ser alugado se alguém
~ chegar diretamente na loja (sem reserva) e retirá-lo.
Quando o carro for devolvido ele irá para a manutenção onde será avaliado e caso esteja
:I
tudo certo, voltará a ficar disponível para um novo aluguel. Se determinados valores forem
atingidos (carro com mais de um ano ou com mais de 15 mil quilômetros) o carro será posto à
::11
venda e sairá do escopo do sistema da locadora. Este fato é identificado pelo estado final.

: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

INSTITUTO INFNET - 108


r

::I
UML-1550

=­:3 <i.
c

....I
o Diagrama de Componentes



«
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

INSTITUTO INFNET -109


:a

!I
I
i UML-I55:
I

<i.

Diagrama de Implantação
Cl
~
o
.C(
I

o­c(
o
=>
Cl

...ww Servidorde Aplicação

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

Mostra como estão configurados o hardware e o software dentro de um determinado


'.
i

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:

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

do sistema por inteiro.


::!lI of-
W
a: - O RUP é uma proposta de metodologia de
C
<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

<t
U
::J
C
W

W
Z
u,
1. A Equipe (Whole Tearn)
~
c:
o
D.

• Composta pelos desenvolvedores e pelo usuário


Ul

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

• Estimativas e prioridades
J.2 fJtr0 {Jft.<J LÁA
88

XP sugere um conjunto de atitudes (práticas) que auxiliam no atingimento dos objetivos e


na implantação dos valores:
1. A Equipe (Whole Team)
Em um projeto XP todos fazem parte da equipe, incluindo um representante do
cliente. Esta equipe é responsável pela coleta de requisitos, identificação de
prioridades e definição do rumo do projeto.
2. Testes de Usuário (Customer Tests)
Os testes são elaborados pelo usuário e implementados como testes automáticos.
Devem ser executados em cada passo do projeto e se rodarem com sucesso indicam
que a funcionalidade foi implementada.
3. Versões Pequenas (Small Releases)
Pequenas partes do sistema são entregues assim que ficam prontas, ou seja, o usuário
pode utilizar o sistema à medida em que ele vai ficando pronto e não apenas na fase
final. O risco é menor, o cliente consegue mensurar a evolução do trabalho e
problemas são reportados imediatamente.
4. Jogo do Planejamento (Planning Game)
O cliente cria as histórias de cada iteração do projeto (normalmente 2 semanas),
definindo as prioridades e desenvolvedores avaliam a dificuldade e estimam prazo e
custo.

INSTITUTO INFNET - B8

Vous aimerez peut-être aussi