Uml E O Processo De Desenvolvimento

:11I

UML-1550

=­

=­

=­

:31

=­

=­

::li =­

UNimo ~OOWijG

UII!"!~GE

~

:li

=­

=­

:li

,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. • 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 • Padrão OMG (UML 1.1 -1997) 63

A Unified Modeling Language é uma notação que normatiza um conjunto de diagramas. É uma linguagem para especificar, visualizar, construir e documentar os artefatos de software e também para a modelagem de negócios. 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] - Rumbaugh, entre outros Fusion, Shlaer-Mellor e Coad-Yourdon), por isso se chama 'linguagem unificada' e 'processo unificado'.

:3

:li

:w :iI

:=I

:11

=s

INSTITUTO INFNET - 63

UML-I:55:

'~


Definição

I­

--'

o

.0«

o­ o« o

::>

o

• Definição em Três Partes

w I­

W

Z

u,

1. A UML funde os conceitos de Grady Booch, James Rumbaugh e Ivar Jacobson. 2. É genérica e flexível. Pode ser aplicada a uma diversidade de sistemas. 3. Tem como foco uma linguagem de modelagem padronizada e não se preocupa com a metodologia de desenvolvimento.

~ ti:

oa, rn

oo o« > ti:

w

fil

ti:

o·

.0«

rn

s l­

m ti: Õ

rn

o rn o<:l oI­

• Método = Linguagem (UML) + Processo (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. 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 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

, t=

'I:

==

::i

UML-1550


=:i

-.

o >­ ...J

Versões e Certificações

o

o« C>


o

2Y'

:::l

o

w

• A versão atual da UML é a • Algumas partes desta especificação ainda estão em discussão.

>­ w Z

lL

~

::!

li:

:::i

li:

oe, til

oo


>

W til W

• Novidades com relação a versão 1.5:

li:

o

o«

~

• Classificadores aninhados

til til

o

>­

• Melhorias na modelagem de comportamento

jjj li:

Õ

• Melhorias no relacionamento entre modelos de comportamento e de estrutura

til

:::::!

o til oo o

>­

• Certificações oferecidas pela OMG

:!

65

::3

~

::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. Acrescentou diversas novidades como a possibilidade de criação de novos diagramas sob demanda.

~

Certificações

:iI

Fundamental

A OMG oferece três níveis de certificação:

:11

=­

:!I

Você pode trabalhar com os elementos UML mais comuns Você pode criar diagramas UML simples Você está qualificado para ser membro de uma equipe UML Intermediate Você pode trabalhar com vários elementos UML Você pode criar diagramas complexos Você está qualificado para ser membro sênior de uma equipe UML Advanced

:11

Você pode trabalhar com todos os elementos UML

:iI

Você está qualificado para ser gerente de uma equipe UML

Você pode criar diagramas extremamente complexos

:iI ai

INSTITUTO INFNET - 65

================-===-===-====--===-----------­

-

r...

UML-I550

o que é Engenharia de Software?

ci c

':i

...:oo­ ..:

o

::>

c w

I­

W

Z

• A Engenharia de Software envolve o gerenciamento de

três "forças":

LL

~

IProces~

ao

oQ.

'" oc ..:

> ao W

W '" ao

o

'..:

'" '" o

Ferramentas

I-

m ao

Õ

'" o s'" o I­

Infra-estrutura incluindo tecnologias

Atividades que precisam ser executadas e fases que precisam ser cumpridas

r-

"'" r

,pesT_

~

r

--= -r

Responsáveis pela execução das atividades e pelo gerenciamento do processo

68

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

r

-

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 continuamente através de treinamento, incentivos e satisfação em participar de projetos bem sucedidos. 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.

INSTITUTO INFNET - 68

r

-

i

-=

!:

r-

:li

=­

=­

:li

=­

=­:=11I

:li

~

Engenharia de Software

-

:< :::> ~

• "Equilíbrio de Forças"

:ii:

--l~~~~~ ~~===;;I//

ãz

...

Processos

~

!:

i:

Pessoas

r---- Sucesso

..~ >

::

iOS

JII.

1----+ Confusão

JZ JII.

::

..

Falsos Inícios

:< !!

Frustração

:ii:

~ !!

I

r---- Ansiedade

!

L.-_-----J

Lentidão

~

=­

==-

:11

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


Processos de Desenvolvimento

~

o .« ~ u

:::l

a

• Os processos de desenvolvimento são compostos por diversas fases;

w

I­

W

Z

u,

;;l;

a:

o<>.

• Em cada fase é necessário executar diversas atividades. • Esse esforço tem como alvo principal a construção de um sistema de qualidade.

l/l

o a

« >

a: w

l/l

W lI:

o .« CIl l/l

o

l­

m a: Õ 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

:31

==-:I =-:3 ~

<' !O

Processos de Desenvo!;~e~~oj.o

--'

~ o

<

~

E

• Ciclo de Vida

.u Z

L.

~

~

Tradicional

~

Iterativo (RUP)

~~íí)<7..eg--o Extreme Programming

MU:l"~~$P1

:< >

.. .. I:

.11 .11

I:

;;;: ~

E

~

!

~

71

;li

:a :iI

:11

:11 :11

:11I

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). 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 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 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). • 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 que o produto seja útil ao usuário final.

:11

~

:11I ;jI

=­

INSTITUTO INFNET - 71

UML-1550


Rational Unified Process

!:i o

'00:

o­

--.,..-

00:

U ::l C

• Origens

w

tiz

u,

- 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 incrementaI e indica o uso da UNIL. - O RUP é um framework, ou seja, você pode adaptá-lo para as suas necessidades.

~

o::

oDo

rn

O

C

00:

> o:: w rn w o::

o

'00:

rn rn

O

t:: w o::

C rn O rn O

--.::

­

'~

C

~

---'-­

­

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

=­::s

::w

UML-1550


-ec

Rational Unified Process

-=:

't>

«

E i5 ,L; !.LJ

Z

Disciplinas

LL.

~

~

=­::I.

11:

~

Modelagem de Negócios

o

Requisitos

> ::

Análise e Design

~ ::

'"

Implementação Teste Implantação

Õ

C.Qnf\9ura~o e Mudança

:c

~

'"'"x: '"

o n :>::

Geren. de Gerenciamentó de Projero _ _....!--_.........."'"'-!--

Q

=t

o Q

IIIIIIIIiIl~

.......

Ambiente

·0 C

e

::I

73

:t

:I

=­

Descrição em Duas Dimensões 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.

::I

• A segunda dimensão, vertical, representa o aspecto estático dQS processo, como é descrito em termos de atividades, fluxos de trabalho, artefatos e pessoas - é o eixo de conteúdo.

::I

O final de cada iteração é marcado pela entrega de um artefato de software (uma versão, um módulo, um conjunto de diagramas), esta entrega pode ser para validação com o usuário ou para teste da equipe.

:t ::I

::I

:ti

Podemos observar que o compromisso de desenvolver um sistema, envolve diversas atividades que são executadas continuamente durante todo o projeto. 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. 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 Modeling" e "Requirements".

::I

::J

~

INSTITUTO INFNET - 73

UML-I55:

-

r ~

-

RUP: Requisitos

~ o

.« ~

[Now SstemaJ

o

if

[Si si:ema Existentej

::::l

C

W

[No'J3 Ertra:la]

I­

W

Z

lL

~

~

-

D:

oo.

I~

Anaisa- o Problema

Ul

oc

t

«

~ w [fi

[Problema Incorreto]

-

Ge-enciar Requisitas tvt.Jl:á.....as

~

p:

o .« Ul

[Não posso fazer tO~,Q o traJalho)

Ul

o

~

--~"i~ijil--
!::: w D:

Definir o

Gerendaro Escopo

[TnDalhã

Õ

Sistema

do aatema

no sscopo]

-

Ul

o oc

~

Ul

g Refina- ~

r

-

Definição do Sstema

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

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.

r

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

-

-

'ir

-

~

-

1f

~

INSTITUTO INFNET • 74

~

~

UML-1550

::I

::I

::I

:I ~

::li

:I

=t :.t

:I

:=I

q;

c .... .....

RUP: Análise e Projeto

o

o« o­ -c o

::::l C W

.... W Z

lL

:?: EC

O O­

O '" c

-c

>

EC

W

'" w

EC

O

o«

'" O '" ....

Refinar a Arquitetura

U;

EC

E

'"O '"Oc

Projetar Co mpcnernes

Projetar o

Banco de Dados

O

....

75

Fluxos da Análise e Projeto: 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), 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.

:I

Projetar Banco de Dados (Designer, Designer do Banco de Dados, Revisor): identificar classes persistentes, projetar estrutura do banco de dados, definir estratégias de armazenamento e recuperação de dados.

=­

:!I

Refinar Arquitetura (Arquiteto de Software, Revisor): identificar mecanismos e elementos de design, descrever arquitetura e distribuição. Realizar Síntese Arquitetural (Arquiteto de Software): demonstrar que há solução arquitetural viável para satisfazer os requisitos do sistema.

:li

:11

:iI

:ti

INSTITUTO INFNET - 75

UML-I550


o

'
o => c

Esirut urar o tIobdelo de Implementação

UJ

t

lüz

mJ,

u,

~

Pl:an~ara

a: ~ til o c

Integração

,j,

-


>

a:

~

UJ

til

UJ

~

[Componentes Testados em Unidadesdisponíve:is]

o

'
[Mais Componentes para Implementar nessa Iteração]

til til

o

!::

[Mas

UJ

a:

'~:t~~~~a~~

til

essalteraç:ào]

Õ

o til o

_""I'""'.....a;.,._ _~

E

[Feita)

C

~

E

76

-

~

Fluxos de Implementação:

E

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

implementação com o objetivo de minimizar conflitos. 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.

j

E ....

Integrar cada Subsistema e Sistema (Integrador): integração dos novos componentes e geração de versões do software.

.

~ (svl~r:~ ~ Af~f&rP!' él9U<.

o~(~Wt}~

<=>d'--o

f[.


/

1', /

,4c::y\.{;J~N'")

-

E

~

-

E

INSTITUTO INFNET - 76

~

=­

UML-1550

:11I

==-::-

:-

:11I

~

RUP: Testes

-

<:D

lEI

~ n

Definir Missão

deATiação

z

z

..... ~

t

E

§:

~

g

r--~

VerifiGarAbordag em

<

do Teste

>

E

ll.

I

'"

ll.

Validar Estabilidade do Build

t

~

(Outra Técnica]

E

:< == == c

Realizar Missão

Testar e Avaliar

Aceitável

e-

t

i: E

::5

:3

==­ :::.

:11

=­::31 =­ ~

:s

s.

>Ir

~'

O

c

AprimorarVantagEns do Teste

c

}

~ 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. Verificar Abordagem do Teste (Gerente de Testes, Analista de Testes, Testadores): verificar se a abordagem definida funcionará e estabelecer a infra-estrutura. 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.

=­::J

::I

INSTITUTO INFNET - 77

:21

UML-155W


a

RUP: Implantação.

I­

....I

O

-o« o o«

~:

U

p-i-~-~;J~r Implantação

::>

a

w

I­ W

Z

u.

i!E a: O e,

"' üesenvower Material de Suporte

'"a O

Gerendâ~T~·ste de

Aoeitação
nesewotv i mento>

o«

~

>

a: w

'"a:w Ó

.0«

Produz.ir Unidade de Implantação

'"'"O !::

..

w

[R etease do

a: Õ

'"O '"a

Client:l::r::< 'f

[""e•• ê ·""1

""1eI1 -:-: : : : : : : : : : : :-:-:-: :_-;: Produto de Teste Beta

[Softv..<are Descarregával]

O

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

-

-

r

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

­

~

INSTITUTO INFNET - 78

ir

-,-'---------'--

- - ­

• UML-1550

Rational Unified Process

-

.;;( J

<

=:

• o RlTP é uma implementação do modelo de

iI

espiral, no qual as fases se repetem e se sobrepõem • Ciclo de Vida:

-

:ui li:

:5

:::

o

:::

o := o

Concepção

Elaboração

Construçã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


Fase de Concepção

S o

.C(

~

o => c w

• Na fase de concepção é estabelecido o contexto de negócio para o sistema e delimitado o escopo do projeto. • O contexto de negócio inclui também um critério de sucesso, ponderado em função de recursos e tempo. • Devemos elaborar um cronograma básico de

execução com as principais fases e datas

• Nessa fase o sistema é descrito através de um texto sumário, resumindo o que é o sistema, e de um diagrama de Caso de Uso geral, contendo os atores e as suas principais funcionalidades.

I­

w

Z

u,

~

a::

o n. (f)

o

cc( > a:: w w

(f)

r;<:

o

.C( (f) (f)

o

~

w

a:: Õ (f)

o (f) o c o I­

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 cronograma básico de execução com as principais fases e datas de entrega.

'I:

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

-

i!

INSTITUTO INFNET - ao

•

UML-1550

11

11


Fase de Elaboração

-'

o

-o:

t>

11

-c o

5

lU

• Consiste de uma análise mais refinada do sistema a ser construído, juntamente com um plano detalhado de trabalho a ser feito. • Elaboração de um projeto completo, com o detalhamento de interações e estrutura do sistema. • Construir um protótipo que teste a arquitetura

escolhida.

• Nessa fase os Casos de Uso são completamente detalhados, são elaborados todos os diagramas de classes identificadas, são feitos protótipos das telas e o projeto lógico do banco de dados é elaborado.

.... OJ

... Z

li

~

::I:

o

"­

o '" c

-c

11

>

I:C l!J

'"

l!J ::I:

o

-o:

11

et:I

CIl

o ....

iü

c::

Õ

11

et:I

o oo o....

cn

iI

iI

11

!

81

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

I:~

UML-I65:

I ~

I­ ...J

o '-C> o:

Fase de Construção

:1

• Trabalhamos sobre o protótipo da fase anterior adicionando novas funcionalidades e refinando as funcionalidades pré-existentes. • O gerente do projeto define várias versões que devem ser liberadas a cada ciclo. • A cada ciclo é necessário rever os requisitos de cada parte da aplicação. • Nessa fase os módulos do sistema são implementados e refinados em ciclos (iterações). O projeto físico do banco de dados é implementado.

I

i3

::>

"w

I­ W

Z

u,

~

a:

oQ.

CJl

o "-o:

> a: w CJl w .a:

o '-CJl

o: CJl

o l­ m a: C

CJl

o CJl o

"

~

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

Fase de Transição­

:J c « o­

« :.J

::::I

::l

• Nessa fase o software pode ser instalado em ambiente de produção para que os clientes possam trabalhar com ele - versão beta. • A medida em que testes são executados e melhorias são implementadas é produzida a versão final do produto. • Nessa fase, além da versão beta e do produto final, são produzidos os manuais e componentes de distribuição do software.

:.ll.

iu

z L

~ OI:

~

CO

O

::l

«

> c: Lt.!I. Q

:.tJ.

c: O

«Q

:I

ii

:3

""o ""o ::>

Q

2 OI:

Õ

e

:3 83

:3

:3

:I

:3

=­

:I

Nessa fase o software pode ser instalado em ambiente de produção para que os clientes 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 ? 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. 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 público-alvo.

:I

:I

:i

:t :i ~

INSTITUTO INFNET - 83

:=I

UML-1550

::li

:11

=-:a

~

Extreme Programming (XP)

.<:>

~"<"",-,,,~",,,,,,,,,,~"'=--'--''''~''.~~---'--'''~"-'- ,~-" - .,. - ­

<

~

:ii

• Processo ágil de desenvolvimento • Criado por Kent Beck, Ward Cunningham, and Ron Jeffries em 2000

;

z

~

~

~

t­

u ~

< >

:I

:z:: u ;a,

• Objetivo principal: entregar o software que o cliente quer no momento em que ele precisa

""

:z::

.... :11 .... ~ o

• Menos formalização e mais disciplina

Ü

:z::

~

:i o c

• Sugere práticas para alcançar valores

::l

:::

~

=­ =­

~

~

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:

!I


II

Valores do XP

~ o .« o­

« o

:::l C

w

1. Comunicação

luz

LL

~

Maior comunicação entre membros da equipe Não é limitada por processos formais

D:

o O­

'" o c «

> D:

11:

2. Simplicidade

W

'"w

D:

o

.«

Redução da complexidade do sistema Não projetar de maneira genérica

'"

'"o

!:: w

D:

Õ

:~

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.

L.~.-============-===~~~

INSTITUTO INFNET - 86

r

r

:li

lIML -1550

:I

:11

:I

e""

Valores do XP

....J

o

< o­ <

~

s

.1C

.L!

%

3. Feedback

.L

;?;

=-

::

3

J:

Tanto sobre a qualidade do código quanto sobre o seu funcionamento

~

15'"

<

>

.,"" ""J:

4. Coragem

.. :li ..

<

Jogar fora práticas que causam problemas

c

~

.. § :I!:

=-

:5

o

31

-•

11

iiII

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. 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. Ambas as práticas permitem que:

11

Erros sejam detectados e corrigidos imediatamente

11

As decisões sejam tomadas de forma mais fácil, mais segura e com menos riscos

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

11

11

• 11

•

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: Mexer no código que está funcionando para tomá-lo mais simples. Jogar trabalho (código) fora quando for necessário Mexer no proj eto a qualquer momento Pedir ajuda

INSTITUTO INFNET - 87

a

a

:I.

=­::J

UML-1550

::'

Práticas do XP

-

:
::I

~

ir ~

•

~

::J

~

::I

•

>: z.!

Todos são responsáveis

Integração Contínua (Continuous Integration)

'">: '" :<.,

.,

7.

2

8. Metáfora (Metaphor)

•

E

>:

.,c .,

Õ

~

Parece que uma pessoa fez todo o sistema

Posse Coletiva (Collective Ownership)

6.

~

< >

::I

J

5. Padrão de Codificação (Coding Standard/)

:Li: z

•

9.

~

E

Várias vezes ao dia Analogia para facilitar o desenvolvimento

Ritmo Sustentável (Sustainable Pace) •

Prazos adequados

:I 89

:3 ::I

::I

=­

~

:I

=­2

5. Padrão de Codificação (Coding Standard) Definição de padrões para nomes de classes, variáveis, métodos, tabelas, campos, constantes, estruturas, posição de chaves, identação. 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) 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, 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 :iI

INSTITUTO INFNET - 89

UML-J550


a

Práticas do XP

:; O

.«

o­

« O => a w

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

f­

w

Z

lL

~

•

a:

O

o.. rJl

Troca e alternância

~

,~

11. Projeto Simples (Simple Design)

O

a « > a: w

•

ffi

.a:

Apenas o que é necessário

O

.«

12. Orientação a Testes

rJl rJl

O

!::. w

•

a:

Õ

(Test-Driven~

Teste primeiro, programe depois

rJl

O

13. Refatoramento (Refactoring)

rJl

O

a

O f­

•

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 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 de um programador sozinho mas a qualidade do código melhora significativamente. 11. Projeto Simples (Simple Design) 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. 12. Orientação a Testes (Test-Driven) Os testes são desenvolvidos antes da programação iniciar. Os testes são automáticos e executados constantemente. 13. Refatoramento (Refactoring) 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

I I

I

I I

I INSTITUTO INFNET - 90

-

I

~

UML-1550

~

~

ffi.•. : -

:;iI

<é Cl !:;

Vantagens

o

-.: o­q: o :::l Cl

w

• Foco na codificação (programas pequenos)

I­

w

Z

LL

:i!:

• Envolvimento do usuário

ti:

o11. cn

oCl

• Trabalho em equipe e comunicação

-c

>

ti: W

cn

• Responsabilidade pela qualidade

W ti:

o ,q:

cn cn

• Simplicidade

o

to w ti:

• Testes frequentes

Õ

cn

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

t=I ~

t:3

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

~.".' ~

~.' ~

t=i

~.

~ d:,

~

INSTITUTO INFNET - 91

ai

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

e-­

-=

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. 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 funcionais restritivos que limitam a funcionalidade do sistema (desempenho, disponibilidade, segurança, etc) não são suportados pelo XP.

e:=

~

ce=

==

~

.-...

­-

INSTITUTO INFNET - 92

-

tT:9

1,"1

~il

a

:I

UML-1550

:s­

:B

ei o

Processo Sinaples

f­ ...l

o


o­

«

u

::3

~

a

w..JI f­

• Processo usado no curso para a solução dos exercícios, laboratórios e estudos de caso.

'U

Z

:I

~

o::

oo­

::o

o

• Passos:

a

-c

::I

> o::

1. Elaborar documento de visão 2. Identificar funcionalidades (requisitos funcionais) 3. Detalhar funcionalidades

""'co

",

o::

o


:=í

co co

o f­

W Ir

Õ

:I

::o

o co o o

oI­

:I

93

:3

:11

:3

:3 ::3 :B

::3

::3

:i

:ii

Os processos de desenvolvimento são apenas diretrizes e sugestões sobre como projetar 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 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. 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 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 "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, 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 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. 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 encontradas subtarefas comuns a várias funcionalidades.

:iI =8

INSTITUTO INFNET - 93

._j.\iF~

UML-I550


Processo Simples.

~ o '
U

=>

c

...ww

•

Z

Passos:

LL

õ!: o: o "­

li)

o c o: w

13

.0:

o

'
li) li)

o

!:: w

o: E

4. 5.

Identificar casos de uso Associar telas a casos de uso

6. 7.

Detalhar casos de uso Desenhar o(s) diagrama(s) de casos de uso

8.

Identificar classes de negócio

-

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

=­ =­ =­

;I

~

Processo Sinaples

...c '"«o­ ~

c :.Li<

•

.c

...

Z

~

9. Identificar relacionamentos

l::

~

:I:

10. Detalhar as classes de negócio

C

~

> z:

11. Desenhar diagramas de sequência

:til.

'"

'L!.

:>: C

12. Identificar estados

-o:

:I

Passos:

'" c '"

Ü

:>:

3"

:3

'c" '" 'o o o !~

;I 95

~

:3

:I

:I

:I

:I

Identificar os relacionamentos das classes: Desenhar o diagrama de classes e identificar 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. 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. 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 identificados. Este processo é feito de maneira iterativa e incremental, assim como o RUP. A cada passo, 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

:I

:t :I :J

são: • Projetar Banco de Dados • Identificar requisitos não funcionais • Relacionar requisitos não funcionais a casos de uso • Definir arquitetura • Identificar classes de projeto

INSTITUTO INFNET - 95

::J

----

-,--,--,---­

:11I

UML-1550

:11I

::11

=­ =­

~

Diagramas: Visões do Sistema

-o

<:;; o(

Q

s ..."" Z

L.

~

..'" o

e,

o

:l
:11 . :>

li: .cJ

.IJij

:li:

o

<

:11

=­ 3

=­ =­ 3

=­:iI :­

:­

'" ... SI

O,

E

'" :5

'" O

'" o

::l

...o A UML integra várias visões do sistema 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: Estrutura Mostram as partes do sistema de forma estática, sem informações sobre o funcionamento. 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

«

Diagramas Básicos da UML

'" ~

o ,«

~ o

::>

'w"

Oiagrama Objetos

I­

w

Z

lL

~

++

o::

+

oO­

++

+

CIl

o

'" «

> o::

w CIl w

.0::

o .« CIl

CIl

Diagrama de Componentes

o

!:: w

o::

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

INSTITUTO INFNET - 100

::I

UML-1550

:2

ci

~

c ,...

Fases X Diagramas _

...J

o

-:o:

o­


::I

:::>

'" ,... z"" t:J:

Captura de Requisitos

-

u,

:!::

:li

o::

o

a,

oc'" <:(

::w

::a

>

Atividades

(fluxo de trabalho,

casos de uso)

li:

er

'" '" o li:

«

'",...o '" Ui

a:

Õ

:I

=­

=­ =­:­

~

:­ :I

:I

'"o

'"o ...o

Análise e Projeto

-

Construção

Atividades (comportamento objeto, AlgOrItmo,operação)

Cl

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

:s

INSTITUTO INFNET -101

UML -155oD

oi

a

Exemplo de uso da UML

:; O

'
o­


U

'" a LU

• Cenário de uma Aplicação

tüz

u,

~

- Este cenário apresenta oito diagramas UML utilizados na modelagem de um sistema de software para uma locadora de veículos. - Tem como objetivo apresentar uma visão geral do uso da UML na modelagem de sistemas.

te O

C.

cn O a


6:LU cn

LU

.

te O

'
cn cn

O

!:: LU

te Õ

cn cn O a O

O .....

102

INSTITUTO INFNET -102

'li

a

==­

=­:=li

UML-1550

~

-

< ::;:lo

:li

==:a ~

=­

~

ã

:;;: Z JL.

;; !:

L !!:

cliente

< > li:

JlI.

'a

~tirar car~

JlI.

li:

< llIt

.>:

! :li:

~

~

llIt

9

103

:I

:11

Especifica uma interação entre um usuário e o sistema, no qual o usuário tem um objetivo 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).

::I

O diagrama de casos de uso fornece uma visão geral do escopo do sistema. Cada caso de 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.

:11

No sistema da locadora, existem dois atores: cliente e atendente pois ambos usam o sistema para realizar tarefas diferentes:

:11 :li

O cliente faz a reserva de um carro; O atendente registra a retirada do carro; O atendente registra a devolução do carro.

:li

=­

=­ =­

:ti

INSTITUTO INFNET· 103

lia UML-1550

oi

c

Diagrama de Classes.

~

o

-..: o <[

Carro

u :> c

-placa

!.LI

!.LI

-mode Lo »chas s

u,

-e e c edc

>­

Aluguel -dataAluQuel

f---~o-,,·---1-daLaElltrada

í

Z

~

1,,*

-preco

li:

O

....

e,

"'

Aqência

O

o

>

-endereco -fone

w

-gerente

<[

li:

"'

-t-r eae rver ()

+retirar () +devo 1ver ()

Cliente <nome

Funcionario

!.LI

-endereco -fone

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

=­:JI

UML-ISSO

/ ~

A

equencia

~

c

<: IJ

<:

g

:11

i:

i: z

...

~

~

:3

=­:3

:li:

~

1 : Soliclação do Carro()

"oo"

« > :: e,

4 : carro

'" '"O <:

6 ; dados pessoasf)

.

perfodoO

LI

:

3 : Iist., de carros

~

T~------------------------.--~lJ ~O, ~O ~

e

2 : buscarCarrosO

5; calcularAluguel()

<xcreece>

'" 'O" f-

7

9 : verificarl-tlstoríco() :

i:] II:

li

Õ

ee O

'"

O

,

i

K-----------------:-------­ 11 ; ccnbrmeçêo

10 : efetuarReserva()

[

O

O

i­

3

:I

=­ =­

:­

:3

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

:J

:3

:i :i :ii

INSTITUTO INFNET -10S

UML-I550

:1:

E:


Diagrama de Comunicação

!:J

..o­.: o

~

..: o

r=

::::l

o

w

tu

z IL

:i!: li:

o Q.

~

sn o o ..: > li: w

1: Solicitação de Carro 3: Informa Reserva (data,carro) 5: Identificação Pessoal -~ IFronteira

I

: Cliente

<Jl W li:

8: Cadastra eserva()

...:o <Jl <Jl

;/

~

m li: C in o in o

I: Aluguel I I I

o

~

2: BuscaCarro( ) 4: Calcula Aluguel( )

I I

-~

---1 ~~~~

~v~~,~t'I";OOI

<E-­

I:

I

11: J

~

I : Client~=1

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

Diagrama de Comunicação

~

o

'
to>


o c w

::> I­ W

Z

1: Solicitação de Carro 3: Informa Reserva (data.carro) 5: Identificação Pessoal

u,

~

a:

oa.

~

CIl

o c

rFr~

I


> a:

W

CIl

: Cliente

w

a:

o

8:

'
CIl

CIl

o

ina:

r

cad/~:erva( )

p~

CIl

o CIl o c

~

~

~~car~~1

6~aHistoriCO( )

~-

//

15

2: BuscaCarro( ) 4: Calcula Aluguel( )

CI~ie_nt_e

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

:l

:J

::!

:!

:!

:!

-•

- •

:i

:3

:3 ~

:I

::11

<­

Diagrama de Máquina de Estados

::::t

:::i

o

...: '-"
::> ::::t L; ~

~

~

ii:

O

"­

O '" c

«

~--__

Cancelar Reserva.--------L----.

'"

Reservado

Disponível

>

I!!!J

'" !!: ~

O

'
'" ,O '" >­

Retira Carro

i:i

Retir

!i:

arro

ã

[ carro ok]

[ > 1 ano ou >15000 krn ]

'"

,O

O '"

~ _ _~Em

'"g

Manutenção

107

Este diagrama é bem conhecido e utilizado há bastante tempo. Ele mapeia diferentes estados em que se encontram os objetos. Desencadeia eventos que levam os objetos a se encontrarem em determinado estado em um dado momento. A figura acima mostra uma visão dos possíveis estados de um objeto da classe Carro durante sua existência. 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 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 à venda e sairá do escopo do sistema da locadora. Este fato é identificado pelo estado final.

:iI

:i

:iI

:Jj,

:iI

INSTITUTO INFNET -107

J

1I UML-I~'

li •


c

Diagrama de Atividades

o

'-o: 00 -o: O

::> C

UJ

l;j Z

u,

~

a: o..

Veriflcar Histórico do Cliente

O

<Jl

O C

-o: > a: UJ

fna:

Obter

I~ormações Pes50ai~ ~

O

[ ok]

'-o: rJ)

~

:>-

~~

Rejeitar Cliente

[ há problema,]

<Jl

O

!:::

UJ

a: Õ rJ)

O

Confirmar

<Jl

~e3erva

~

~.,

O C

g

-r

108

É 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 este tipo de lógica do que o diagrama de sequência pois este normaimente indica apenas o fluxo normal de execução.

-r

É 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

=­:3

UML-1550

­ o o« o­

Diagrama de Componentes

....I

« o

:I

::>

...c ...z>­ "­

~

::I

r----------

ti:

o "­ co

g

o '" « >

:I

:x: ur

co

1!l ti:

~

I

SistemaWEB.DLL

-----1 I

I I I

1 I I

~'''ml

o

>«

:JI

I

I

I

'" '"o

>­ W ti: C

I

I I

I

o '"

~

'" o o o >­

:I 109

:!

::I

Mostra como os diferentes subsistemas de software formam a estrutura total de um sistema. As dependências entre os diversos componentes também são mostradas neste diagrama.

:I

:i

:! ~

::I ::!

:i

es ::2

:a

INSTITUTO INFNET -109

r

!I I

UML-I55:

i


Diagrama de Implantação

Cl

~

o .C(

I

I

o­c( o

=>

Cl

...ww

Servidorde Aplicação

6

Z

LL

~ tE:

oD­

---

g

c(

~

Servidorde Negpcios

w w

O O

CIJ

tE: '0 .C(

SíslemaWEB.DLL

~----I

,, ,, ,

g

CIJ CIJ

o

...m tE:

,, ,, ,, ,

--------~

,

,r--------­

CIJ

oCl

P' , 'OO A5 P

r---------------

5"'''''".DLL I

I

Bencceenerícc.Du, I

,,

15

CIJ

o CIJ oCl o

Servidorde Banco de Dados

i

,

•

êf:j

...

i

110

'.

i Mostra como estão configurados o hardware e o software dentro de um determinado 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 ~

:iI

:11

o

Conclusão da UA.2

f­

....I

o

-o:

o­
:::>

D W

- A UML não tem uma metodologia embutida, permitindo que o desenvolvedor use os diagramas como bem entender. - Cada diagrama da UML mostra uma "visão" do sistema. Nenhum diagrama permite ter a idéia do sistema por inteiro. - O RUP é uma proposta de metodologia de desenvolvimento de sistemas que usa a UML como notação.

l-

w

Z

IL

t:

::!I

a:

oc..
oo


:3

> a: w
a:

O'

-o:
::!lI


of-

W a:

C


:!I

O


O

o

o l-

:3 111

:3

:!I

:3

:3

~

=­ =­

:3

:11

:3

:I :21

INSTITUTO INFNET - 111

,X.tA _

UML-I55J


Práticas do XP

~

o

.
C

W I­ W Z u,

1. A Equipe (Whole Tearn)

~

•

c:

o

D.

Ul

o

Composta pelos desenvolvedores e pelo usuário

2. Testes de Usuário (Customer Tests)

C


~

w

• Elaborados pelo cliente

Ul W

c:

o

.
3. Versões Pequenas (Smal1 Releases)

Ul

:g t: w

• A cada versão o software é funcional

c:

Õ

4. Jogo do Planejamento (Planning Game) ~J'"

Ul

o

Ul

oc o

I­

• Estimativas e prioridades

~ ~/~~r;\ffl 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