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:

'~





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



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 ~

::

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

w

I­ W

Z

u.

i!E a: O e,

"' üesenvower Material de Suporte

'"a O

Gerendâ~T~·ste de

Aoeitação

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

(f)

r;

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

=­ =­

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)

.

~"

: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

:

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



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



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

Captura de Requisitos

-

u,

:!::

:li

o::

o

a,

oc'"

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

'­

Aluguel -dataAluQuel

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

í

Z

~

1,,*

-preco

li:

O

....

e,

"'

Aqência

O

o

>

-endereco -fone

w

-gerente

-

~~

Rejeitar Cliente

[ há problema,]

­ "­

~

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



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