uml - guia de consulta rapida (2001)

8/3/2019 UML - Guia de Consulta Rapida (2001)

http://slidepdf.com/reader/full/uml-guia-de-consulta-rapida-2001 1/50

G U I A D E

C O N S U L T A,

R A P I D A

Doug las Marcos da S i l va



Guia de Consulta Rapida UML de Douglas Marcos da

Silva ra desse guia 5

Ul;ao 11orienta9ao a·objetos 6

Ob jeto

Oasse 7

Polimorfismo 8

Heran9a 8

. letodos orientados a objetos 9

u9ao 11UML 10

Origem e evolu9ao da UML 10

Diagramas na UML IO

Diagrama de casos de uso 10Diagramas de intera9ao 11

Diagrama de gnificos de estados 12

Diagrama de atividades 13

Diagrama de classes 13

Diagrama de componentes 14

Diagrama de objetos 14

Diagrama de implanta9ao 15

Como os diagramas se relacionam na UML 15

Prop6sitos da UML 16

oque a UML nao e 16

Onde pode ser utilizada a UML 16

Eleme ntos da UM L .: 17

Bloeos de constru9ao da UML 17

estaticos 18

Classe 18Colabora9ao 18

Caso de usa 18

Componente 19

dinamicos 19

Intera9ao 19

Maquina de estados 19

P.acotes 20

......................................................................................... 20

Relacionamentos 20

Associa9ao 21

Agrega9ao e composi9ao 22

Generaliza9ao 22

Especializa9ao 23

Realiza9ao 23

oem utilizando a UML 24

J.Jodelagem da arquitetura de sistemas 24

A importancia da modelagem 25

Construindo model os 26

~Iodelagem orientada a objetos 27

I)ggrama de casos de usa 27

Alor 28

Varia90es na especifica9ao de casos de usa 28

Erros comuns na especifica9ao de casos de usa 31

Relacionamentos entre casos de usa 32

Arquitet ura de sistem as ori ent ada a casos de uso 34

~Iodelando diagramas de casos de uso 36

Como fazer 37

Todos os direitos reservados. E proibida a reprodugao

desta obra, mesmo parcial, por qualquer processo, sem

previa autorizagao, par escrito, do autor e da Editora.

Novatec Editora Ltda.

Rua Cons. Moreira de Barros 1084 Conj. 01

02018-012 Sao Paulo - SP Brasil

Tel.: (Oxxll) 6959-6529

Fax: (Oxxll) 6950-8869

E-mail: [email protected]

Site: www.novateceditora.com.br

mailto:[email protected]

http://www.novateceditora.com.br/




mailto:[email protected]



Diagrama de classes 38

Atributos , 41

Operacroes 42

Pre-condicrao 44

Pos-condicrao 45

Operacroesversus metodos 46

Analise de casos de uso 46

Como f azer 49

Diagrama de objetos 50

Estrutura de objetos 50

Diagramas de interac;ao 51

Diagrama de seqUencia 52

Diagrama de colaboracrao 54

Introducraoaos objetos 54

ReaIizando casos de uso 55

Auxilio aos desenvolvedores 56

Como f azer 57

Diagrama de gf lificos de estados .......................•.................. 58

Estados 58

Evento 59

Transicrao 59

Analisando os estados para urn objeto 59

Como f azer 60

Diagrama de atividades 60

Thread condicional 63

Concorrencia dinamica 64

Raia de natacrao 65Diagrama de atividades versus diagramas de interacrao 66

Como fazer 66

Diagrama de componentes 67

Componentes 68

Interf aces 69

Outros tipos de componentes 69

Sistemas base ados em componentes 70

Como f azer 70

Diagrama de implantacrao 71

A UML no ambiente f f sico 71

Uso comum 72

Como fazer 72

Mecanismos de extensibilidade da UML 73

Estereotipos 73

Restricroes 78

Alguns padroes para restricrao 78

OCL (Object Constraint Language) 79

Ferramentas que suportam a UML 80

Rose 80

Visio 80

PowerDesigner 80

Onde obter mais informacroes 80

Versoes da UML 81

Dif erencrasentre as versoes da UML 81

Glossario 84

Obtendo mais informacroes 92

Consulte a UMLBrasil 92

Consulte 0autor , 92

fndice 93

trutura desse guia

o topico lnt r odur ;iio a orient ar;iio a objetos e apresentada

uma visao geral da orientayao a objetos, seus principais

conceitos e os metodos orientados a objetos mais usados

nos ultimos anos.

Em lntrodur;iio a UML e dada uma visao geral sobre todos

os conceitos da UML. Sao apresentados os diagramas da

UM L, os relacionamentos, origem da linguagem, entre

outros assuntos . Recomenda-se a leitura desse capitulopara a formayao de uma base conceitual sobre a UML.

o topico Mod elagem utili zando a U ML , antes de

entrarmos mais detalhadamente nos diagramas da

Iinguagem, apresentam-se uma pequena introduyao amodelagem da arqui tetura de sistemas orientados a objetos

e a importancia da modelagem de sistemas. Em seguida,

e abordado minuciosamente cada diagrama da UML.

Em Ferrament as que supor tam a UML, sac apresentadas

principais ferramentas que suportam a linguagem

, contendo tambem 0site de cada fabricante.

A pendice sac ressaltadas as principais diferenyas

tre as vers6es da UML, ocorridas ao longo de sua

evoluyao.

II



Introduc;ao a orientac;ao a objetos

A orientac;iio a objetos surgiu como uma nova forma de

modelar e construir sistemas de sof twares, isto e , organizar

e geriros conhecimentos manipulados e registrados dentro

de uma empresa. No desenvolvimento de urn sistema

orientado a objetos, dados e process os siio organizados e

manipulados por objetos, e niio por programas.

Vantagens da orientaC;iio a objetos :

• Reutilizac;iio dos objetos

Os dados e os processos siio manipulados por objetos,

niio ficando engessados dentro de program as, isto e , os

objetos construfdos podem ser utilizados pordiferentes

sistemas.

• Modularidade

o sistema e formado por objetos e niio por programas,

facilitando 0 trabalho e a manutenc;iio desses objetos

no futuro.

• Utiliza-se dos mesmos conceitos da realidade na

construc;iio de sistemas de sof tware.

A orientac;iio a objetos baseia-se em conceitos da realidade

- objetos, estados e estfmulos - para modelagem e

construc;iio de sistemas de software. Dessa f orma, 0usa

da orientac;iio a objetos se toma mais natural, pois os

conceitos utilizados siio os mesmos que ja conhecemos,

s6 que aplicados nesse casos ao desenvolvimento de

sistemas.

II

Pode ser qualquer coisa na natureza que possua

aracterfsticas e comportamentos.

• mna abstrac;iio de urn conjunto de objetos que possuem

mesmos tipos de caracterfsticas e comportamentos.

s I i :~_''l .:::... ~ -- - -

c.ro de passeio Carroesportivo

II



Polimorfismo (do grego "muitas formas") refere-se aos

process os que varios objetos podem executar, dado apenas

a solicita~ao de uma unica opera~ao. No ambiente

polim6rf ico, todos os objetos con tern uma mesma

opera~ao, que e implementada por metodos particulares

a cada objeto (a diferen~a entre opera~6es e metodos e

apresentada na pag. 46).

E 0 compartilhamento pelas classes especializadas

(subclasses) dos atributos e opera~6es de classes mais

gerais (superclasse).

Automovel

esportivo

as conceitos da orienta~ao a objetos sao explorados em

mais detalhes no decorrer deste guia.

II

Nos ultimos tempos houve uma grande evolu~ao na

engenharia de sof tware, que pas sou a contar com tecnicas,

como a analise, 0pro jeto estruturado e a Engenharia da

Informa~ao. as metodos orientados a objetos surgiram na

decada de 70, procurando melhorar essas tecnicas.

A seguir sao apresentados resumidamente alguns metodos

que surgiram para a orienta~ao a objetos.M etoda Descri~iio

B ooch C onsis te em tecn icas do desenho o r i en tado a ob je tos. Esse

metodo u til iza -se do desenho de ob j e tos, que servem como

base para a cr iacao dos mO dulosdo s is tema . Esse metodo lo i

criad o por G rady Booch (Ra tiona l So ftw are) .

O MT 0 m e to d o O M T ( O b je ct Model i ng Techn iq u e ) cons i s te na

m od elagem sem a n tica de dad os, suportando os conce ito s

de :• Mode lagem de dados (a tr ibutos e relac ionamentos).

• Ob je tos ( compos i cao e ag regacao).

• H era nca.Esse m e to do lo i c ri ad o p o r Jam es R um bau gh (G E

C or pora tion ).

Os concei tos apresentados antes tam bem sao u ti l izados pe la

UML, e sao deta l hados a pa r t ir da p agina 20 .O O S E 0 m e t o d o O O SE ( O b jec t O r ien t ed So l tw are Eng ineering) ,

consis te n a ana lis e d o s r e q ue r im e n to s d e u m s is t ema

u tiliza ndo casos d e u se, cr iand o cat ego ria s pa ra pessoas e

equ ipa m ent os com que esses casos in teragem . Esse me to do

lo i cr iado por Ivar Jacobs on .as conce ito s ap resentados antes tam bem sao u ti l izados pe la

UML e sao deta lhados a pa r t ir da pag ina 27 .

C oa d IY o u r do n P e t e r C o a d e Ed Y o urdon d i v i d i ram a ana l is e o rien t a d a a

ob je tos em c lasses e ob j e tos . D en tro desse contex to , os

ob je tos sao rel ac ion ados pormeio dos conce itos de agregaca o,

genera lizacaolespec ia lizacao , as sociacoes , c o nexoes e

. m ens a g ens.

II



Introdu~aoa UML

A Unified Modeling Language (UML) e 0 resultado da

unifica~ao dos metodos Booch, OM T e OOSE, que da

origem a uma linguagem padronizada para a modelagem

de sistemas de sof tware orientados a objetos, sendo

adotada pela industria de software como linguagem-

padrao, e tambem por fornecedores de ferramentas CASE.

Os trabalhos para a cria~ao da UML iniciaram-se em

1994 com Grady Booch da Rational Software (metodo

Booch) e James Rumbaugh (OMT), que combinaram

seus dois metodos mais populares.

V e rs iio A n o P rinc ipais 'a los oco rr idos

U M L 0 .8 1995 L an 9am en to do p rim eiro esbo90 da U M L.UML 0 .9 1996 In tegra9ao de Iva r Jaco b so n ile qu ip e d a

R ation a l S o ftw a re , e se u m etodo O O S E ilexpansao do escopo da U M L ; fo rm a9aode um co nsorcio de em presas , co m 0objet ivo de ap o ia r a de lin i9ao da U M L .

U M L 1.0 1997 A U M L l oi subm etida c om o c and idata a

Ii nguagem -padrao de m ode lage m ilO M G(O b jec t Managem en t G ro up , um a en tidadede padron iza9aoes tabe lec idape la i ndus t r iade sof tware) .

U M L 1 .1 1997 Expansa o do con so rc io form ado p orem presa s pa ra ap o ia r a def in i9ao da UM L ,e ace i ta9ao da U M L pela O M G .

U M L 1.2 199 8 R e v isoes e nova s padron iza90es.

U M L 1.3 199 8 R e v isoes e n ovas padron iza90es .

Diagrama e a representa~ao graf ica de urn con junto de

elementos do sistema. A UML disponibiliza nove

diagramas que permitem representar diferentes partes do

modelo de urn sistema.

o diagr ama de casas d e usa representa urn conjunto de

atores, casos de uso e os relacionamentos entre eles.

Os diagramas de intera~ao representam colabora~6es

entre ob jetos, para realizarem algum tipo de

comportamento para um sistema.

Os diagramas de intera~ao sao representados por :

• Diagrama de sequencia.

• Diagrama de colabora~ao.

Odiagr ama de seqiiencia da enfase a ordena~ao temporal

em que as mensagens sao trocadas entre os ob jetos de um

sistema. Podemos entender por mensagens, os servi~os

solicitados porum objeto a outro, e asrespostas devolvidas

a essas solicita~6es.

[te rn Estoque]

AtualizarQ

III



Introdu~ao it UML

Diagrama de colabora~ao

Introdu~ao it UML

o diagrama de colaborar;iio da enfase a ordena<;ao

estrutural em que as mensagens sao trocadas entre os

objetos de urn sistema.

Diagrama de atividades

o diagrama de atividades representa a modelagem do

fluxo de controle de uma atividade para uma outra no

sistema. Sao exibidos os estados das atividades e a<;6es,

transi<;6es e objetos.

t 1 : R egistra rO

2 : Ve r if i carO

3: [ te rn Es toqueJ :=A tu a liza r O--;r...

{ Efeluar pedido

(~" Esloque

Diagrama de graficos de estados

o diagrama de graficos de estados representa os estados

possfveis de urn objeto em particular. Sao exibidos os

estados de urn objeto, eventos, transi<;6es e atividades.

Pode ser usado principal mente para a modelagem de

estados de classes e colabora<;6es.

Diagrama de classes

o diagrama de classes representa a estrutura (esqueleto)

de urn sistema, sendo encontrado geralmente na maioria

dos sistemas orientados a objetos. Sao exibidos classes e

seus respectivos relacionamentos.

NotaFiscalPr od ut o I

cod igocod igo

Ina turezaO pe ra ca onome

condica oPa game ntovalo rUnitario i

t ipoPrestSe rv ic o

Ida ta E m issa o

0 ..'1. .- In se rirQ

v alo r ReeuperarQ

R egistrar QExc luirQ

IR ec uper arOAt ua liza rQ

Can eef ar Q I

II



Introdu~aoit UML

Diagrama de componentes

o diagr ama d e componentes representa urn con junto de

componentes e suas respectivas dependencias, podendo

ter como base de sua constru<;ao os diagramas de classes.

o d iagr ama de objetos representa as instancias das

classes de urn sistema, em determinado ponto no tempo.

c: Cliente

codigo = 145100

Nome = "Joao da Silva"

cont: Contrato

numero = 00125

Natureza Operacao = "Venda"

II

o diagr ama de implantar;iio representa a configura<;ao e

a arquitetura de urn sistema em que estarao ligados seus

respectivos componentes, podendo ser representado

tambem a arquitetura ffsica de hard wares, processadores,

etc. Com 0 diagrama de componentes, representa os

aspectos ffsicos de urn sistema.

(Todos os diagramas apresentados ate aqui serao

explorados com maior riqueza a partir da pag. 24).

Como as diagramas se relacionam naUML

Os diagramas da UML representam diferentes partes do

modelo de urn sistema. No quadro a seguir, edemonstrado

como os diagram as se relacionam, formando toda a

modelagem orientada a objetos.

1 1



A UML nasceu com 0prop6sito dedocumentar, visualizar,

especificar e construir sistemas de software orientados a

objetos.

Prop6sito Descri~ao

Arte l a tos com o r equ isi~ 6 e s d e n eg 6c ios, m odele dearqu ite tu ra , c6d igo -Ion te , m o d e lo de ana lis e , p rot6tipo e

out ros documento s qu e servem de in lorma~ao sob re 0

sistema, podem se r docu m en tado s co m a U M L.

No processo de desenvolvim en tode sis temas de softwar e ,e quase im poss ivel a visua liz a~ao de toda a es tru tura deum softw a re sem 0 use de m ode los que a repr es en te .Dessa lorma, a UML d ispon ibi liza sim bolos gra ficos par aa representa ~ao de a rtel a tos de softw ar e .A UML e u m a I inguagem que aten de a todos osrequ isitos

de especi lica~ao den tro de um processo , de sde a lase deanalise ate a lase de tes tes e implem enta~ao do sistemaconst ru ido.

Na UML e possivel rea l izar um mapeam ento dos modelosgerados, para Iinguagens de programa~ao e a te mesmopara banco de dados re laciona is ou or ientados a objetos .

A UML nao e uma linguagem de programa~ao visual, esim uma linguagem para modelagem visual. Apesar de

oferecer suporte a diversas linguagens de programa~ao, a

UML e uma linguagem para a constru~ao de artef atos de

sof tware que servem para a tomada de decisao quanta it

defini~ao de arquitetura, implementa~ao, etc.

A UML nao e urn processo de desenvolvimento, mas

pode e deve ser aplicado a urn. A UML, como uma

linguagem de modelagem, pode e deve ser aplicada a urn

processo de desenvolvimento de software, assim como

outras linguagens utilizadas para a constru~ao de artef atos

de software. Em Un! contexto de processos, a UML se

prop5e a tratar, em diversos domfnios, diferentes

problemas e em diferentes organiza~5es.

A UML pode ser aplicada a qualquer tipo de sistemas de

software. Por ser uma Iinguagem muito abrangente, ela

pode ser usada tambem para modelar process os de

trabalhos, projetos de har dv'are, etc.

as elementos da UML sao as simbologias e nota~5es que

utilizaremos para construir os modelos orientados a

objetos. Nessecaso, os elementos principais sao os blocos

de constru~ao.

as blocos de const r u~ao da UML sao as materias-primas

utilizadas pelos diagramas para representar partes de urnsistema de sof tware.

Entre os blocos de constru~ao existentes na UML,podemos

observar:

• Itens.

• Relacionamentos.

as itens sao os blocos de constru~ao da modelagem

orientadaa objetos. Existem quatro tipos de itens na

UML. Sao eles:

Tipo Descri~ao

Rep res en tam a es tru tura do m odelo , e lement osconce ituais e fis ico s (c las ses, cola bora ~6e s, casos

de use, et c .).Def inem 0com por tam en to do modele (inte ra~ 5ese es tado s dos objetos) .Sao as par tes organ izac iona is da UM L.

Sao as pa r tes exp licat ivas do m o d e le n a U ML

(com en tar ios e observa~6es de esclarecimentos

no mode lo ).

Pacote s

N ota s

II



Os itens est aticos representam 0esqueleto e a estrutura

estavel de urn sistema.

Urn componente e a parte fisica de urn sistema. Existem

dif erentes tipos de componentes, como os componentes

COM+ e Java Beans (mais detalhes na pag. 67).

Uma c1asse e urn conjunto de objetos que compartilham

os mesmos atributos, opera~oes e relacionamentos. Erepresentada graficamente como no exemplo a seguir:

N otaFisca l

cod igo

na tu rezaO peracaocond icaoP agam en totip 0P r e s t S e rvi c 0

dataE m issaova lo r

R eg ist ra rOR ecupe ra rOC anc elarO

Os itens d inamicos representam as partes de urn sistema

que possam ter alguma altera~ao. Existem dois tipos

principais de itens dinamicos. Sao eles:

• Intera~ao.

• Maquina de estados.

Representa a realiza~ao dos processos de urn sistema, por

meio da troca de mensagens entre 'os objetos. Pode

envolver mensagens, seqtiencias de a~oes e conexoes

entre os objetos (mais detalhes n a pag. 51).

Uma intera~ao e representada por uma f1echa cheia, como

no exemplo a seguir:

Uma colaboraf(iio e 0nome dado a intera~ao entre duas

ou mais classes, com 0 objetivo de fomecer algum

comportamento cooperativo. Ocorrem por meio da troca

de mensagens entre dois ou mais objetos (mais detalhes

na pag. 54).

Representa urn comportamento que especifica as

seqtiencias de estados pelos quais os objetos passam

durante sua existencia, de a cordo com os eventos

atendidos. No exemplo aseguir, temos urn estado possivel

para 0 objeto "V enda".

Urn caso de uso e urn documento que descreve os cemirios

pretendidos para urn sistema, com 0objetivo de atender

as necessidades do usuario (mais detalhes na pag. 27).

E representado graficamente como no exemplo a seguir:

V e n d a

P e n d e n t e

II



A S pacotes organizam os modelos criados na UML.

Todos os blocos de constru~ao criados na UML (casos de

uso, classes, componentes, etc.); bem como os diagramas

que tratam desses blocos, podem ser organizados em

pacotes.

Deve-se fazer essa organiza~ao observando a semelhan~a

de cada bloco e diagrama da UML, no que diz respeito a

solu~ao do problema que cada urn esta empregando.

As notas representam comentarios, observa~6es e

esclarecimentos que podem se utilizar para qualquer

elemento da UML. No exemplo a seguir, a representa~ao

de uma nota informando a ultima versao de uma classe.

Ultima

versao : 2.0

as relacionamentos reunem os itens criados na UML.

Existem seis tipos de relacionamentos. Sao eles:

• Associacao.

• Agrega~ao e composi~ao.

• Generaliza~ao.

• Especializa~ao.

• Realiza~ao.

Uma associa~ao descreve relacionamentos entre objetos.

Cada associa~ao tern duas pontas, onde em cad a ponta

esta ligado urn objeto. Por exemplo, poderfamos ter urn

relacionamento de associa~ao entre 0 objeto Cliente na

primeira ponta, e 0objeto AnaliseCredito na outra ponta.

NotaFisc a l

P rodutocod igo A ssocial' aocod igona tu rezaOperacao

1cond icaoPagamento n om e

tipoPrestServico va lo rUnitario

da taEmissao1. . " In serirOva lor 0 .. "

~~~RecuperarO

Re g ist rar O ExcluirO

RecuperarQ M ulti pl ic ida de Atua li za rO

Cancela rQ

E a indica~ao de quantos objetos podem participar dedado relacionamento. No exemplo anterior, pode-se dizer

que 0 objeto NotaFiscal pode ter urn ou mais objetos

Produtos, enquanto esse objeto pode zero ou mais

objetos NotaFiscal.

Na UML, temos basicamente os seguintes tipos de

multiplicidades:

o (zero)

1 (um)

0..1 (zero ou um)

0..* (zero ou mais)

1..* (urn ou mais)

* (muitos)



Introdu~aoit UML

Agregatrao e compositrao

A agrega<;ao e urn tipo de associac;ao na qual 0 todo e

relacionado com suas partes (urn objeto todo contem os

objetos-partes - relacionamento todo/parte). Erepresentada como uma linha de associac;ao com urn

diamante junto a classe agregadora.

PessoaFisica ContaBancaria

dataNascimen to Ban cosexo AgenciaRG ContaCPF tipoContasalario valUmiteestadoCivii tipoEspecial

A compoSlc;ao e urn tipo de relacionamento muito

semelhante a agregac;ao. Em uma composic;ao, 0 objeto~

parte pode pertencer somente ao objeto-todo. A Iem disso,

geralmente 0 objeto-todo vive e mOITecom suas partes,

isto e, acontece uma remoc;ao em cascata. E representadacomo uma linha de associac;ao com urn diamante preto,

junto a classe agregadora.

PessoaFisica

dataNascimentoClienteReferencia

sexo

RG Nome

CPF Telefone

salario tipoRe ferencia

estadoCivil

Generalizac;ao e a capacidade de se criar supertipos que

encapsulam a estrutura e 0 comportamento comum a

varios subtipos. Os procedimentos para se obter a

generalizac;ao sac:

• Identif icar similaridades de estruturalcomportamento

entre varias classes.

• Criar 0 supertipo para encapsular a estrutura e 0

comportamento comum a mais de uma classe.

• Os objetos originais passam a ser subtipos do novosupertipo criado.

Especializatrao

A especializac;ao e a capacidade de se criar subtipos que

representam ref inamentos nos quais a estrutura e /ou

comportamento do supertipo sac adicionados ou

modificados.

Os procedimentos para obter a especializac;ao sac:

• Perceber que algumas classes apresentam estrutura e/

ou comportamento especializado.• Criar subtipos de acordo com sua especializac;ao.

C lion to

cod ig o C lient e

no me Cliente

En do rocoBairro

C id adoCEP

T olo (on0 1T olo(on0 2

P e ss o aF isicad a taN a sc im enta

sex o

R G

CPF

salario

esladoC ivil

Pe ssoaJur idica

C N PJ

ins cricao E stad ua l

ra mo A tivi da dof aturam entoAnual

num Fu nc ion ario s

A realizac;ao e urn relacionamento entre itens, em que urn

item implementa comportamentos especificados por

outros. Pode ser realizado entre interf aces e classes ou

componentes que as realizam; e entre casos de uso e as

colaborac;oes que os realizam. E representado por uma

seta pontilhada, como no exemplo a seguir:



Modelagem utilizando a UML


Antes dos diagramas da UML serem apresentados urn a

urn em detalhes, sent demonstrado como e dividida a

modelagem de urn sistema orientado a objetos e o'uso da

UML nesse contexto.

A arquitetura de urn sistema representa urn conjunto dosartefatos e elementos que formarao 0sistema. A arquitetura

deve abranger como este sera construido, seus elementos

estruturais e comportamentais, suas colabora~5es, entreoutras.

Construir sistemas de software e uma tare fa que requer a

visualiza~ao da arquitetura desses sistemas sob varias

perspectivas e em diferentes niveis de detalhamento.

Todos os en volvidos na constru~ao de sistemas - gerentes,

analistas, programadores, usuarios finais - necessitam

visualizar a arquitetura de urn sistema sob perspectivas

diferentes, pois a necessidade de entendimento de cadaparticipante nesse processo influenciara seu tra:balho

futuramente quando 0sistema estiver pronto.

Portanto, a arquitetura de urn sistema deve ser visualizada

por meio de cinco vis5es:

V i s a o

Caso de uso

D esc r i 9ao

Essa v isao foca l i za os compor tamentos de um s is tema, Av isao deve ser t r ansparen te pa ra todos os envo lv idos naconstru~ao do sistema -gerentes , anal istas, programad ores,usuar ios f inais.

Diagramas ul i l izados; d iagrama de casos de use, d iagramas

de intera~ao, diagrama de al ividades e de graf icos de estados.

Essa visao focal iza a estrutura (esqueleto) de um sistem a. Av is a o s o b e s s a" pe r spec t iva d emo ns tr a a s c l asses ,

colabora~6es e as inter faces de um sistema em constru~ao.D iag ramas u l il izados : d iag rama de c lasses, d iag ram a de

objetos, d iagrama de intera~ao, d iagrama de at ividades e degraf icos de estados.

II

P ro ce ss o E ss a vis ao fo ca liz a a s q ue st6 es d e d es em p en ho ,e s ca la b il id a de , m e c a ni sm o s d e c o nc o rr en c ia e d e

sincroniza~ao, Diagramas ut i l izados; os mesmos diagramasda visao de projeto.

Implem enta~ao Essa visao focal iza os ar tefatosl isicos para a efet iva mon tagem

do s is tema. Sao abordados com ponentes e ou t ros a rqu ivosque servem para a montagem do s is tema.

Diagramas ut i l izados; d iagrama de componentes, d iagramas

de intera~ao, diagrama de at ividades e de graf icos de estados.Imp la n t a~a o Essa v i sa o fo ca li z a o s no s qu e fo r ma m a t o pol o gi a d e

hardware em que 0 s is tema sera execu tado .Diagramas ut i l izados: d iagrama de implanta~ao, d iagramasde intera~ao, diagrama de at ividades e de graf icos de estados.

Antes de entrarmos mais detalhadamente nos diagramas

da UML, e necessario entendermos a importancia de se

fazer a modelagem dos sistemas de softwares que voce

construira.

Vamos imaginar uma possivel situa~ao. Voce trabalha

para uma grande rede de lojas de departamentos, onde

saG comercializados diversos produtos como

eletroeletr6nicos, eletrodomesticos, informatica e outros.

Essa rede automatizara toda a sua area de concessao de

credito, e foi designado a voce a condu~ao de todo 0

processo de constru~ao de urn sistema que atenda as

necessidades de neg6cios dessa empresa. Esse sistema

sera encarregado de realizar toda a analise de credito dos

cIientes dessas lojas, seguin do uma rigorosa polftica de

credito estabelecida pela diretoria.

Esse sistema deve fomecer informa~5es sobre 0credito

do cIiente, por meio de Orgaos de Prote~ao ao Credito,

realizar analises pelo Credit Score, conferir as informa~5es

pessoais prestadas pelo cliente, enfim, verificar 0

enquadramento do perfil desse cIiente junto as polfticas

de concessao de credito da empresa.

A menos que ja tenha feito diversos sistemas com as

mesmas requisi~5es de neg6cios, voce certamente

precisara fazer urn planejamento antes de come~ar a fazer

a primeira linha de programa~ao.

Nesse caso, voce devera estimar 0tempo necessario para

que esse sistema seja desenvolvido, bem como qual sera

o custo do seu desenvolvimento. Sera preciso estimar

tambem quais serao os recursos humanos envolvidos

nesse processo, bem como 0 custo de cada recurso, suasresponsabilidades, entre outras atividades.



Dessa forma, para que tudo saia con forme suas estimati vas

(ou 0mais proximo disso) voce com certeza necessitara

de todos os modelos e esbo~os desse projeto que

demonstrem a complexidade do processo e os riscos

possfveis. Alem disso, voce desejara manter todo 0

processo documentado, pois em manuten~oes futuras

desse sistema e, caso os desenvolvedores iniciais nao

estejam mais presente, vocecertamente nao passaraapuros,

esperando que cada linha de codigo seja decifrada para

que se entenda como 0processo funciona. Voce tambemdesejara que, no proximo sistema que sera desenvolvido,

se possa reutilizar os process os ja criados anteriormente,

sem que seja necessario "reinventar aroda".

Uma das variaveis que farao com que esse processo seja

bem-sucedido e a utiliza~ao da modelagem. Nao quero

atribuirtoda aresponsabilidade do sucesso de urn sistema,

somente pelo fato do uso da modelagem. E evidente que

a escolha de bons profissionais com 0esfor~o em equipe

(e principalmente, 0 apoio de todos os envolvidos nesse

processo) se torna indispensavel para que se atinja 0

objetivo proposto.

Imagine a constru~ao de uma nova casa, urn novo predio

ou ate mesmo urn aviao, sem que seja construfdo primeiro

os seus respectivos modelos. Seria urn erro cuja propor~ao

nao poderfamos estimar. Milhoes de vidas seriam

arriscadas (e certamente perdidas) se nao houvesse

model os em que pudessemos visualizar 0que futuramente

vira a ser realidade, possibilitando a corre~ao de erros

antes que fossem concebidos os produtos finais.

Enfim, construfmos model os para compreendermos

melhor 0sistema que estamos desenvolvendo.

Com a modelagem, podemos alcan~ar:

• A especifica~ao da estn,1tura e do comportamento do

sistema.

A visualiza~ao do sistema como ele e ou como

desejamos que ele seja.

• Documentar todas as decisoes tomadas.

II


Modelagem orientada a objetos

A visao do desenvolvimento de sistemas nos ultimos

anos, vem adotando uma perspecti va orientada a objetos.

Sob essa perspectiva, 0principal bloco de constru~ao do

sistema e 0objeto.

Nao ha duvidas de que os metodos orientados a objetos

tern consolidado seu uso na constru~ao de sistemas de

diferentes domfnios de problemas, sendo simples ou

complexos.

Urn diagrama de casos de usa representa urn conjunto de

cenarios identificados, que seja util aos usuarios de urn

sistema.

Urn caso de uso descreve cada cenario possfvel para urn

sistema, composto por seqiiencias de passos em que ha

intera~ao entre os usuarios e 0sistema.

Caracterfsticas de urn diagrama de casos de uso:

• Capta 0comportamento desejado para urn sistema, pormeio da analise dos requisitos necessarios para a

constru~ao do sistema.

• Permite enxergar melhor a abrangencia dos requisitos

de urn sistema, pois utiliza-se de recursos grMicos para

estruturar esses requisitos.

• Perrnite documentartodos os requisitos de urn sistema.

• Sua estrutura e extremamente simples, pois os cenarios

sao formados por textos, descritos em uma linguagem

informal, possibilitando 0entendimento nao somente

da equipe tecnica, mas por todos que participam do

processo de desenvolvimento de urn sistema.

• Permite organizar os requisitos, eliminando as

redundancias de informa~oes por meio dos

relacionamentos entre os casos de usa (mais detalhes

na pag. 32).

• Permite identificar os riscos possfveis para a fase de

constru~ao do sistema.

• Pode ser usado em todas as fases no desenvolvimento

de urn sistema, orientando na defini~ao da arquitetura

ate os testes funcionais do sistema.



Sao papeis desempenhados por qualquer usmmo de urn

caso de uso, ou seja, 0ator e quem solicita os servic;:os

disponfveis em casos de uso.

Urn ator pode ser :

• Uma pessoa que interage com 0 sistema.

• Urn hardware que interage com 0sistema.

• Urn outro sistema que tenha a necessidade de utilizar

o caso de uso.

Urn caso de uso pode ser especificado de diversas formas,

pois nao ha urn padrao estabelecido para essa atividade.

Foi dividida em duas formas neste guia a maneira de

especificar casos de uso:

• Caso de uso de alto nfveI.

• Caso de uso detalhado.

A especificac;:ao de urn caso de uso de alto nfvel e uma

forma de expressar 0cOJIlportamento pretendido para urn

sistema, sem se aprofundar em seu detalhamento.

Sob uma perspectiva macro, em uma fase em que nao se

tern todas as informac;:oes consolidadas, os casos de uso

de alto nfvel se torn am uma boa opc;:ao para iniciar 0

processo de levantamento das necessidades de urn sistema.

Na maioria das vezes, na fase de alllilise do processo de

desenvolvimento de urn sistema, os participantes nao tern

todas as informac;:oes prontas na "ponta da Ifngua",

principalmente se estivermos falando de sistemas

complexos, em que estejam envolvidas diversas areas da

empresa para definirem os processos.

Desse modo, os processos devem ser discutidos por meio

de reunioes entre os participantes e as areas envolvidas,

para consolidar os process os em levantamento.

~------:2.,Analista de

Credito

Objetivo: manter os clientes da empresa, onde tambem

seriio submetidos a analise de credito. Os clientes devem

jornecer injormafoes, como rejerencias pessoais e

comerciais , dados projissionais e pessoais.

Ator: Analista de credito.

Exernplo de descri~ao de urn caso de uso

Dica: Os casos de uso de alto nfvel podem ser

utilizados com freqiiencia. Use essa tecnica

para fazer 0 levantamento preliminar das

necessidades, sem se a profundar no

detalhamento. Essa tecnica deve serempregada

para se ter uma visao geral de todos os requisitos

do sistema. Dessa forma, serao obtidas as

informac;:oes relevantes para poder mensurar,

porexemplo, os custos en volvidos e os recursos

necessarios na fase de analise de urn sistema.




Caso de uso detalhado

Um caso de uso detalhado (como 0pr6prio nome sugere)

mostra mais detalhes do que um caso de uso de alto nfvel.

Ap6s 0 levantamento inicial dos casos de uso de alto

nfvel, teremos uma visao melhor para decidirmos qual

sera 0 caso de uso, que deve ter prioridade em rela9ao a

um outro, no que diz respeito ao seu detalhamento.

o objetivo desse detalhamento e descrever a seqUencia depassos que deve ocorrer para 0 respectivo caso de usa,

sem a omissao de qualquer informa9ao.

~~

7--------"'---.- // ----- - - - - ~

. . ma ntemClientes~,

Analista de

Credito

Especifica~ao detalhada do caso de uso

mantemClientes

Objetivo: manter os client es da empresa , onde tambem

seriio submetidos a analise d e cr edito. Os clientes

devemfomecer informafoes, como refer encias pessoais

e comerciais, dados projissionais e pessoais.

Ator : Analista de cred ito

Descrifiio: esse caso de uso come fa no cadastramento

de uma proposta de jinanciamento pelo Analista d eC redito, que ser a submetida a uma analise de credito.

Passos:

• C omo as primeiras informafoes a serem fomecidas

siio as infor ma f oes sobre 0 cliente, 0 Analista de

C red ito deve entr ar com os dados pessoais deste ,

como nome do clie;ue , enderefo d e r esidencia, bairro,

cidade. C E P , estado, telefone de contato, nome da

empresa, enderefo comercial , cargo que ocupa, saIario

e data de nascimento.

• 0 Analista de C redito deve entrar com os documentos

de apresentafiio obrigat oria, como 0C PF eo RG.


• Se 0 cliente possuir contas bancar ias , esses dados

deveriio ser fomecidos.

• 0cliente obrigat oriament e d eve apresentar no minimo

duas referencias pessoais ou comerciais , parafuturas

consultas de cr edit o.

• Para toda a manipulafiio dos clientes na base d e

dados, deve ser validado 0 CPF do cliente e se a

cidade escolhid a e verdad eira.

• Deve ser possivel incluir um novo cliente, sempre que

e xistir uma nova pr o posta d e jinanciamento.

• Deve ser possivel alterar os dados do client e, com 0

objetivo de atuali zafiio cadastral.

• Deve ser possivel excluir 0 cliente cadastrado, caso

haja desistencia da proposta de cr ed ito.

• Deve ser possivel consultar os dados d o clientes , onde

o Analist a de Credito devera in for mar 0 CPF ou 0

c6d igo do client e , podendo consult ar t odos os dados

deste.

Erros comuns na especifica~aode casos de uso

C~mo ja foi dito, um caso de uso descreve cenarios

pretendidos para urn sistema. Um erro bem comum no

infcio desta atividade, e confundir um passo de certo

cenario com 0pr6prio cenario.

C)

Descri fiio: esse caso de uso se inicia quando 0analista

de cred ito necessita cadast r ar as r efer encias pessoais

d o client e, que seriio validadas ao longo do pr ocesso

da analise de cred ito ...

o exemplo apresentado refere-se a uma atividade do caso

de uso mantemClientes , e nao a um cenario, ou seja, a

atividade de manter as referencias do cIiente faz parte do

processo de manter os clientes (caso de uso

mantemClientes).




Relacionamentos entre casos de uso

Voce pode organizar os casos de uso por meio de

relacionamentos. A UML disponibiliza tres tipos para

casos de uso. Sao eles:

A generaliza~iio e urn relacionamento de generaliza<;aa/

especializa<;ao em que toda a estrutura do caso de usa

generalizado e herdada pelos casos de uso especializados.

o

analisaCreditoPessoa Fisica

analisaCreditoPessoa Juridica

ocaso de uso analisaCredito (supertipo) con tern cemirios

comuns entre os casos de uso analisaCredito PessoaFisica

e analisaCredito PessoaJuridica (subtipos).

Os subtipos, por sua vez, contem cemirios mais

especializado, particular a cada urn deles.

Portanto, os cemirios comuns a mais de urn caso de usa e

captado em urn caso de uso generalizado, que e herdado

por outros casos de uso mais especializados. Dessa forma,

alem de reduzir a duplicidade dos requisitos entre os

casos de uso, as informa<;6es sao organizadas, 0que tende

a deixar 0processo mais claro.

No relacionamento de inclusiio (include), 0cemmo comum

a mais de urn caso de uso senicaptado em urn outro caso

de uso, ou seja, esse servi<;o estara concentrado em urn

caso de usa base, para que outros casos de uso utilizem-

se desse servi<;o. Dessa forma, evita-se descrever uma

mesma seqUencia de passos a varios casas de uso,

concentrando essa seqUencia em urn caso de uso publico.

No proximo exemplo, ambos os casos de uso

mantemCreditScore e 0 mantemAprovacaoUsuario,

tinham em comum os passos relacionados ao controle das

informa<;6es pelo Log, que consiste em documentar as

a<;6esrealizadas pelos usuarios durante a intera<;ao cam 0

sistema.

Utilizamos 0 estereotipo «include» para expressar

esse tipo de relacionamento (para saber mais sabre

estereotipas, ver pag. 73).

;(l' ''''' \

d 6mantemCredilSs. man~~~~~~acao

• • '" ,"0 0» ~ . ' " "~ • • •

m antem 8aseLo g




Extensao

o relacionamento de extenSGO (extend) e usado para

descrever cemirios opcionais de urn caso de uso. Os casos

de uso descrevem cemirios que sempre acontecerao no

sistema,jaos casos de uso estendidos, descrevem cenarios

que somente ocorrerao em uma situa~ao especffica.

Utilizamos 0 estere6tipo «extend» para expressar

esse tipo de relacionamento.

Observa~ao: com esses relacionamentos,

podemos melhorar a forma como asinforma~6es sao organizadas por meio dos

casos de usa, com 0objetivo de entendermos

melhor a necessidade dos usuarios de urn

sistema.

Arquitetura de sistemas orientada a casos de

uso

Do ponto de vista de urn processo de desenvol vimento de

software, considero os casos de uso como 0 principal

artefato de uma arquitetura de sistemas bem planejada.

Utilize-se sempre desse recurso para planejar a arquitetura

de urn sistema.

II


Descrevendo uma situac;ao no mundo real

Vamos imaginar (agora como clientes) a realiza~ao da

compra de urn veiculo.

Ap6s varios anos, voce finalmente realizara 0tao esperado

sonho - a compra daquele maravilhoso autom6vel, cujo

dinheiro voce guardou na antiga cademeta de poupan~a

durante anos. Pois bern, voce se dirige a uma

concessionaria de sua preferencia, e logo e avistado por

urn vendedor. Voce entao come~a a descrever 0 modelo

do autom6vel que deseja:

Cor vermelha, quatro portas, bancos de couro, ar

condicionado, dire~ao hidraulica, freios ABS, regulagem

da altura dos bancos, air-bag, etc. Baseado em seus

requisitos, 0vendedor consulta 0estoque dos acess6rios

que voce solicitou. Se houver todos os acess6rios

disponiveis em estoque (vamos imaginar que ha), 0

vendedor the informara 0 pre~o final do veiculo e,

provavelmente, 0 dia da entrega. Tudo muito born, nao ?

No dia da entrega do veiculo, voce se dirije aconcessionaria, e aguarda a saida do ve1culo. Ap6s sairem

da concessionaria, naquele calor de mais de 30°, voce

resolve ligar 0ar-condicionado. Mas, ao apertar 0botao,

nada acontece. Voce entao chega a conclusao de que

realmente 0 autom6vel comprado nao funciona como

deveria. Agora vamos traduzir tudo isso para 0 mundo

dos softwares.

M u n d o r e a l

Requ i s i t os do ve i cu lo : cor v erm elha ,a r -eond i c i onado ,a i r - bag , q u a l r o p o r t a s .

P r o du t o e n t r e g ue : co r ve rm e lha , se m

a r - e o n d ici o n a d o ,a i r-b a g , qu a l r o p o r t a s .A r q u i te t u r a n i io o r ie n t a d a a c a s o

de u s o

Foi demonstrado com 0 exemplo apresentado, urn

problema muito comum no processo de desenvolvimento

de software. Quando a arquitetura de urn sistema e definida,

algumas informa~6es sao perdidas ao longo do processo

de desenvolvimento quando essa mesma arquitetura nao

e construida pelas necessidades reais do sistema. Parece

muito 6bvio que urn sistema deva ser construido de

acordo com 0 solicitado. Mas, muitas vezes, 0que nos

parece urn simples detalhe pode ter, e com certeza tera

para 0 usuario final, grande importancia.




Os casos de uso devem ser detalhados ate os ultimos

pass os a serem realizados. Nao economize nas descri~6es

de como e realizado urn caso de uso.

Por exempIo, na fase de constru~ao, os casos de uso

ajudarao na defini~ao da arquitetura de dados, bem como

a arquitetura dos objetos, que serao os responsaveis por

sua reaIiza~ao.

Na fase de testes do sistema, os casos de uso seraoutilizados para validar se 0 que foi construfdo esta de

acordo com 0 que foi especificado.

Os diagramas de casos de uso tern porobjetivo especificar,

visualizar e documentar 0comportamento que cada parte

do sistema deve ter.

Os diagramas de casos de uso apresentam em sua estrutura,

principaImente os tres itens a seguir:

• Casos de uso.

• Atores.

• Relacionamentos.

Com os diagramas de casos de uso e possfvel visualizar

quais serao os servi~os oferecidos pelo sistema.

ConseqUentemente, esses servi~os representam algum

tipo de valor para cada ator que interage com esses casos

de uso.

Alem de especificar, visualizar e documentar as

funcionalidades do sistema, os diagramas de casos de uso

podem ser utilizados para:

• VisuaIizar as funcionalidades do sistema, sob umaperspectiva extema a este.

• Servir como base de informa~6es para a gera~ao das

classes (analisando 0contexto de cada caso de uso),

coIabora~6es (trocas de mensagens entre os objetos) e

os pr6prios objetos.


J --- <)solic ita Pro pos tade F inanciamento

l /analise Credito"

sf 6 ~ro

CreditScore analisaValor Chente

Financiam ento

Como fazer

• Identifique os possfveis atores que comporao 0

diagrama e fa~a uma listagem, atribuindo os papeis que

cada urn deve desempenhar.

Identifique os cenarios do sistema, considerando qual

comportamento 0sistema deve ter, e 0represente por

meio dos casos de uso.

• Paracada caso de uso, identifique e descreva a seqUencia

de passos.

• Preencha 0diagrama de casos de uso com esses atores,mostrando 0relacionamento existente com esses casos.

• Organize os diagramas de casos de uso em pacotes,

agrupando tais diagramas pelo tipo de cenario que

cada urn esta empregando.



o diagrama de classes representa 0modelo da estrutura

de urn sistema orientado a ob jetos. Esse tipo de diagrama

eo centro dos principais conceitos da modelagem orientada

a objetos.

Caracteristicas de urn diagrama de classes:

• Permite visualizar 0modelo da estrutura de urn sistema.

• E urn dos diagramas mais utilizados na modelagem

orientada a objetos.

• Demonstra as classes, os relacionamentos (agregac;ao,

composic;ao, generalizac;ao, etc.) e as colaborac;6es.

As c la sses repre s entam os blocos de construc;ao utilizados

nesse diagrama. Imaginando no mundo real e utilizando-

se do exemplo de urn vef culo, os blocos de construc;ao

seriam as portas do vefculo, as dobradic;as, as mac;anetas,

enf im, todos os objetos que interagirao de alguma forma

para executarem urn comportamento dese jado (no caso

de vefculo, por exemplo, mover-se).

Os r e la c i o n ame ntos, por sua vez', inf orm am em urn

modelo de diagrama de classes como essas classes estarao

de alguma f orma ligadas (associadas) para atender as

responsabilidades que lhes foram atribufdas. Sera tambem

tare fa dos relacionamentos demonstrar os papeis de cada

classe. Os relacionamentos demons tram, por exemplo, a

imporrnnciade cada classe relacionadaa urn modelo quando

for utilizado 0relacionamento do tipo agre g a f QO , em que

serao demonstradas a classe superior e suas agregadas.

Por exemplo, as portas do vefculo estarao ligadas por

meio das dobradic;as, com a responsabilidade de cumprir

urn comportamento quando acionadas. Mas, qual a

importancia das portas e das dobradic;as nesse prbcesso?

As portas estao disponfveis para realizar a func;ao de dar

aces so ao interior do vefculo. As dobradic;as auxiliarao as

portas nesse processo, girando-se e fazendo com que a

porta f ac;amovimentos, permitindo assim a execuc;ao do

comportamento "abrir". Assim, a porta, alem desse

comportamento, deve realizar outros, como destravar-se

e abrir os vidros. As dobradic;as somente estao ali para

realizar 0comportamento de girar-se. Logo, as dobradic;as

sao agregadas da porta, pois sem as portas, as dobradic;as

nao teriam sentido para estar ali.

II

As c ol abo r afoes representam a f orma como as classes

interagirao para executar urn comportamento cooperati yo.

Clienle

codigoClienle

nomeCli enle

EnderecoBairroCidadeCEPTelefone1

Te lefo ne2

i f I I

Pe ssoaFlsica PessoaJuridica

dalaNascime nlo CNPJ

sexo inscricaoE sladual

RG ramoAlivldade

CP F falu ra m en loA n u aI

salatio numF uncionarios

esladoCivii

~

Cl ienleReferencia

No me

Telef onelipoReferenc ia

PIOpO!i1a

codigoProposla&od igolo ja

P ro ou toValorf mantlamenlo

Vi llor Entrada

. " ""Data

polltiUCredilo'·

codl llOPolitlcaC redi to

idad lJMinimavalorM inimoFinanciamenlo

1 wlof ~'aldmoFlnanciarrientovalo rRendaJ ri(in ima .c re d:! iicor e lrl l:inim o




Mapeamento para Iinguagens de programa~ao

Existem ferramentas que ofere cern suporte para 0

mapeamento das classes criadas por meio da UML, para

as linguagens de programac;;aoorientadas a objetos. Apesar

desse recurso, a UML e independente de qualquer

linguagem de programac;;ao. Dessa forma, podemos

representar os modelos na UML sem que obrigatoriamente

tenhamos de atender a padr6es de uma linguagem de

programac;;ao especffica.

Classe Cliente

/ /Source f i le : c : /C l ien te . ja va

pub l i c c l a s s C l i e n t e

p r i va t e i n t cod i goC l ie n t e ;

p r i v a te S t r i n g nom eC l i e n t e ;

p r i v a te S t r i n g Ende r eco ;

p r i v a te S t r i n g Ba i r r o ;

p r i v a te S t r i n g C i d a de ;

p r i v a t e S t r i n g CEP ;

p r i v a te S t r i n g T e l e f one1 ;

p r i v a te S t r i n g T e le fone2 ;

pub l ic C l ien te { )

Voce deve utilizar os diagramas de classes para visualizar

a arquitetura de urn sistema dentro das seguintes formas:

Visualizar as classes de urn sistema, seus

relacionamentos e colabora~oes

Nessa forma e possfvel visualizar quais san as classes que

formarao 0 sistema, bem como os relacionamentos

existentes entre elas e suas colaborac;;6es. Nesse tipo de

visualizac;;ao, 0 mais importante e a possibilidade de

identificar qual e 0tamanho da estrutura de classes que 0

sistema deve ter, e principal mente os tipos de

relacionamento existentes entre as classes.

II

Nessa forma voce podeni identificar, por exemplo, se foi

atribufda a uma classe muitas responsabilidades que foi

atribufda a uma outra. Isso pode ser urn problema

f uturamente para 0sistema, visto que as classes precisam

ser estruturadas dentro de uma harmonia, em que as

responsabilidades de cada classe devem ser equilibradas.

Por meio dos diagramas de classes, voce podeni fazer a

transic;;aodas classes que serao persistidas em banco de

dados, para modelos 16gicos de banco de dados.

No capftulo anterior, discutimos os diagramas de casos de

uso. Essa in vestigac;;ao realizada para cap tar 0

comportamento de urn sistema e a base de toda a formac;;ao

dos outros diagram as na UML.

A descoberta dessas abstrac;;6es do sistema representa

atribuir a realizac;;aode cada caso de uso a elas. Portanto,usaremos no decorrer desse capftulo novos exemplos de

casos de uso e os usados no capftulo anterior, paramostrar

que com a amilise dos casos de uso e possfvel descobrir

quais as classes responsaveis por sua implementac;;ao (dos

casos de uso).

Atributo e uma propriedade de classe. Representa as

caracterfsticas pr6prias de uma abstrac;;ao. Urn atributo

representa algum tipo de propriedade da classe que esta

sendo modelada.

cod igo C l ien ten b lY ie C l ien te ·

idad esexo, .

III




Voce ainda pode representar os atributos, com seu tipo e

valor inicial padrao, como mostra a f igura a seguir:

Cliente

codigoCliente : char = 1nomeCliehte : char

idade : int

sexo:int

As opera~6es SaDprocess os ou servi~os realizados par

uma classe, e disponibilizadas para usa de outras classes

em urn sistema.

Uma opera~ao e disparada a partir de urn evento gerada

para 0sistema. As opera~6es, com os atributos de uma

classe, executam as responsabilidades atribufdas a uma

classe.

consultarQinser irO .

atualizarQ8xcluirO .

Voce ainda pode representar as opera~6es, def inindo a

visibilidade, parametros a serem enviados, etc.

c6nsu ltar(codigoCliente :..int )iriserirO . .. . . ..

atllalizarO

exduirQ .

II

A visibilidade e urn item importante para a especif ica~ao

de atributos e opera~5es de uma classe. A visibilidade

especifica se urn atributo ou opera~ao pode ser utilizada

par outras classes. A UML oferece tres tipos de visibilidade

para essa especifica~ao. Sao elas:

r a p a Sfmb olo Descri~ao

o elemento pode ser utilizado peloob jeto no qual ele perlence e por

qualquer objeto cliente.

o elemento pode ser utilizadosomente pelo proprio objeto aoqual ele perlence, ou se existirem ,

pelas suas subclasses.

o elemento pode ser utilizadosomente pelo ob jeto ao qual ele

perlence.

Cliente

# codigoC liente

# nomeCliente

# Endereco

# Bairro

# Cida de

# CE P

+ Tel efone1

+ Telefo ne2

- consultar(codigoCliente : int)

- inserirO

- atualizarO

- excluirO

As responsabilidades SaDas obriga~6es que uma classe

deve cumprir, por meio de seus atributos (caracterfsticas)

e suas opera~6es (comportamentos).

II




o exemplo demonstrado nesse guia, e a capta~ao dessas

responsabilidades por meio da amilise de casos de uso.

Observa~ao: tive algumas experiencias na

defini~ao de classes em que nao foi utilizada a

analise de casos de uso. Nao deram muito

certo. Prefiro 0uso da tecnica de analise de

casos de uso, apesar da existencia de outras,

como, por exemplo, 0 uso da tecnica dos

cartoes CRC (Class - Responsability -

Collaboration).

Uma classe pode ter qualquer numero de atributos e

opera~oes. Na pratica, uma classe bem estruturada deve

contersomente os atributos e opera~6es que dizem respeito

aelamesma.

Nao e possivel precisar urn numero certo de atributos e

opera~6es que uma classe deve ter. Tente equilibrar a

estrutura de suas classes de tal forma que seja possivel

atingir seu proposito: atender as responsabilidades que

lhe foram atribuidas.

Uma pre-condir;fio e algo que necessita ocorrer antes da

execu~ao de uma opera~ao. Isso significa que 0sucesso

da execu~ao de uma opera~ao esta condicionado ao

atendimento a umaou mais pre-condi~6es. A defini~ao de

uma pre-condi~ao deixa explicito que a responsabilidade

de seu atendimento fica para 0chamador da opera~ao.

Isso ajuda muito quando estamos falando de opera~6escomplexas, pois essa divisao de responsabilidades -

chamador I executor - reduz a complexidade no momenta

em queestarnos escrevendo 0quedeve fazer essas opera~oes.

II

Uma pos-condir;fio e 0resultado que uma opera~ao deve

produzir apos 0termino de sua execu~ao. Ao definir uma

pos-condi~ao, voce implicitamente ja esta definindo qual

eo resultado obtido apos 0termino da execu~ao de uma

opera~ao.

A especifica~ao de pre-condi~ao e pos-condi~ao para as

opera~6es do sistema san as informa~6es necessarias queos chamadores dessas opera~6es precisam saber sobre

elas, ou seja, 0 chamador tern conhecimento do que a

opera~ao necessita para ser executada (pre-condi~ao) e

do resultado obtido apos sua execu~ao (pos-condi~ao).

Da defini~ao de pre-condi~6es e de pos-condi~6es,

podemos ter tambem as exce~6es. As exce96es ocorrem

quando as pre-condi~6es foram atendidas, mas isso nao

sera verdadeiro para as pos-condi~6es.

. AnaliseCredito..

ObterCreditScoreO

Nome da opera~ao: ObterCreditScoreResponsabilidade: obtem a pontuayao atingida para urn

c1iente, de acordo com os dados desse c1iente e da

politica de credito definida

Pre-condi~ao: deve ser inf ormado qual e 0 cliente

P6$-condi~ao: a pontuayao f oi obtida, inf ormando essa

pontuayao ao chamador da operayao.Exce~ao: senao f orem encontrados os dados necessarios

para a obteyao da pontuayao, retornar urn erro




O perac;oes versus metod os

Apesarde muitas pessoas utilizarem opera~6es e metodo

como sinonimos para algumas linguagens de programa~ao,

na VML existe uma distin~ao entre os dois termos. Vma

opera~ao e urn procedimento de chamada em urn objeto,

enquanto urn metoda e 0 que implementa esse

procedimento de chamada. Podemos ver essa distin~ao

entre os dois termos, quando falamos em polimorf ismo.

Por exemplo, quando temos urn supertipo com doissubtipos, em que cada subtipo subrescreve a opera~ao

"Salvar" do supertipo, temos uma opera~ao e dois metodos

dif erentes que a implementam (uma para cada subtipo).

Vamos utilizar neste exemplo 0 mesmo caso de uso

apresentado no t6pico Diagrama d e casos d e uso.

_________0

~. m"lemCII"""

Analista de

Credito

Objetivo: manter os clientes da empr esa, onde t ambem

serao submet idos a analise de cr ed ito. Os client es

devem f ornecer in f ormar ;i' Jescomo referencias pessoais

e comerciais , dad os pr o fissionais e dados pessoais.

Ator : Analist a d e credito

Descrir;ao: esse caso de uso comer;a no cad astrament o

de uma proposta de financiament o pelo Analista d e

Cr edito, que sera submetida a uma analise de credito.

Passos:

• C omo as primeiras in formar ;i'Jes a ser em f ornecidas

Sa D as inf ormar;i'Jes sobr e 0 cliente , 0 Analista d e

Cr edit o d eve ent rar com os dad os pessoais d o cliente,

como 0nome completo, end erer ;o de residencia, bairr o,

cidad e, CEP , Estad o, telefone de contat o, nome daempresa, ender er ;o comer cial , car go que ocupa, saldrio

e data de nasciment o.

II

• 0 Analista de Cr edit o d eve ent r ar com os document os

de apr esent ar;ao obr igat6 r ia, como 0CPF eo RG.

• Se 0 client e possuir contas bancarias, esses dados

d ever ao ser fornecidos.

• 0client e obr igator iamente deve a pr esent ar no minimo

duas r e f er encias pessoais ou comerciais, para f utur as

consultas de cred ito.

• Para toda mani pular ;ao dos clientes na base d e d ados ,

deve ser validad o 0 CPF do client e e se a cid ade

escolhid a e verdadeir a.

• Deve ser possivel incluir um novo cliente , sempr e que

exist ir uma nova pr o posta de financiament o.

• Deve ser possivel alt er ar os dad os do cliente, com 0

objet ivo de at uali zar ;ao cad astral.

• Deve ser possivel excluir 0 cliente cadastrado, caso

haja desistencia da proposta d e cr edito.

• Deve ser possivel consult ar os dados do clientes , ond e

o Analista de Cr ed it o d ever a informar 0CPF ou 0

c6 d igo do client e, podend o consultar todos os dados

d este.

Vamos analisar:

O b je tos do caso de uso

Client es

N o me d o c lien te

En der eyo de res idencia

Bairro

CidadeVal idar a c idade

C EP

Estado

Te le fone de con tat oN o me d a em presa

Endereyo comercia l

Cargo

Salario

Da ta de nasc imento

C PF

R GV a li da r o C P F

Conta bancar ia

referencias

al terar os dados do cl iente

exclu ir 0 cl ien teInclu ir urn novo c1 ien te

consultar os dad os dos cl ien tes

C PF

Caracter is t ica

Cand ida ta a c1a sse

Atribut o do c1 ien te

Atri but o do c1 ien te

Atri buto do clie n te

C andidata a c lasse

C o mpo rta m ent o d ese jad o

Atri but o do cl ie nt e

Atribu to do clie nt e

Atr ibuto do cl ie nt eAtributo do cl ienteAtributo do cl iente

Atributo do cl iente

Atribu to do c liente

At ribu to do c1 iente

Atr ibuto do cl iente

At ribu to do c liente

Compor tamento dese jado

Candidata a classeCand idata a classe

Compor tamento dese jad o

Compor tamento dese jad o

Compor tamento dese jado

Compor tamento desejado

Atribu to do c lien te e candidato a chave depesqui saAt ributo do cl ient e e cand ida to a c have de

pesquisa




Estabelecendo as classes do domlnio

Vamos primeiramente listar as classes identif icadas nesta

analise de caso de uso.

ClienteReferenC ia

ClienteCon taBancaria

Vamos agora identificar para cada classe descoberta, os

seus atributos e os respectivos relacionamentos e

multiplicidades.

Clientes'Cl ien leRe f e renc ia

N omeco dig oCliente

.'. / Te lef o ne

n om C lie n te . : .>1.- .

Ipo R ef e ren cia , _. "cp r ..··· ..R C ) > 1

d at a N a sC im en lc ili paSe xo·· ...

norneE~presa ::: : C lien t eC on ta B a n ca r iat~mpoServico ):

~ cp digo Ba nco .ca ~go::::.... .<::: ':< codigoAgen~ia

sa lario.:···;:: " . < . : : < co digoConta 't!pEn dCq~ranc~ : 0.," va lLi m ite ·

npo~special..

1

L'

C lienteEndereco

Er idere CO ·'Com pl emento .., ·Ci dil de

B a ir i 'o ' :' :' codigoC ida de ,. ,CEp ·., . N om eC .i dada::E$i.d~ '· 1.. 1t e i ~ f o n e :" . .: .. . .. . . .'li po Eiidereci l


Algumas classes como ClienteContaBancaria e

ClienteReferencia, por exemplo, nao tern especificados

no caso de uso quais saD os seus atributos. Dessa forma,

os atributos citados nessas classes sao apenas sugest6es.

Em urn caso de uso real, esses atributos deveriam estar

especificados em caso de uso (nao se esque~a).

Observa~ao: criamos 0 diagrama de classes

apresentado, baseado na analise de casos de

uso. Vamos modelar os comportamentos

identif icados nessa f ase, no t6pico Diagramas

de lnterat ;ao.

Como fazer

• Identifique as classes que farao parte da estrutura do

sistema, par meio da analise de casos de uso.

• Identifique as caracterf sticas para cada classe.

• Fa~a com que as classes nao sejam sobrecarregadas

com muitas responsabilidades. Distribua as

responsabilidades harmonicamente, visando manter

urn equillbrio em toda a estrutura do sistema.

• Junte todas as classes descobertas para 0sistema e as

coloque em diagramas de classes. Estabele~a os

relacionamentos que devem existir entre as classes,

explicitando a importancia e a fun~ao de cada classe no

modelo.

• Detalhe a estrutura de cada classe e dos diagramas de

classes, definindo 0 tipo de cada atributo e a

multiplicidade nos relacionamentos entre as classes.



o diagrama de objetos representa a modelagem de

instancias das classes de urn sistema em determinado

ponto e momenta de execu<;ao.

o diagrama de objetos pode ser considerado uma varia<;ao

do diagrama de classes, pois se utiliza de quase todas as

suas nota<;6es. 0 objetivo do diagrama de ob jetos e

mostrar as instancias das classes de urn sistema emdeterminado momenta de execu<;ao desse sistema.

Nesse caso, os objetos saGdif erenciados de suas classes

por terem seus nomes sublinhados. Cada ob jeto tern 0

nome na seguinte forma: nome d a instancia : nome da

classe. Apesar de nao s e r tao importante quanta urn

diagrama de c1asse, 0diagrama de objetos pode a juda-Io

na compreensao de diagramas complexos que nao estejarn

muito c1aros.

~co d lg o Pro pos ta = 102 310 1

codlgolo ja = 10

Pf odU f O=l D479 S89

V aJ o rF ina nc iam en lo = 1 .50 0 ,00Val Of E nttada = 50 0,00

Pr a zo > ::5

ValO f'P arcela = 2 90, 0 0

Oa t; = 0510212001

IP O IC red lto :P oli ti caC redito

cod lgoP o litlca C fe d ito = 1ida de M inima,.lS

lorM lnlmo Flm lO cla me nlo = 20 0,00

alorM ax im o Financiame nlo = 2.000,00ralorRendaM inlma = 500,00

c r ed itS co re M ini m o = 25

codlgOAnallse=lDO

Data= 05 lO2J2001

H o ra = 02 :2 5 P M

R esponsav el = MaliaR e sul tad o = A prov a do

I

Sco re :An aliseCred itsc o re

cr edltS coleC llenle = 35c re d itS co re M in im o = 25

Data"0 5f02J2001

s ta tu s = A provad o

I Renda:AtlaliseRenda

valO iRen d aln fo r ma da = 1 .000,00va lolR e n da M in ima,. 500 ,0 0

Oala=05J02120 0t

Sla lu s = A + l rova do

Os diagramas de objetos saG utilizados tipicamente na

modelagem de estruturas de objetos, para mostrar os

objetos de urn sistema funcionando em determinado

ponto no tempo.

Os diagramas de intera<;ao - formados pelos diagram as

de seqUencia e diagramas de colabora<;ao - representam

a dinarnica de urn sistema. Os diagramas de intera<;ao

mostram como os ob jetos colaboram entre si para a

realiza<;ao de urn cornportarnento.

Os objetos colaboram entre si a partirdaintera<;ao existente

entre os atores e 0 sistema. A partir dos eventos geradospelos atores, havera de ter opera<;6es em resposta a esses

eventos, ou se ja, 0evento e urn estfmulo gerado pelo ator

no sistema, e as opera<;6es SaGas respostas a esse estfmulo.

Porexemplo, quando 0ator solicitar ao sistema a inser<;ao

de urn novo c1iente, entre outras coisas, 0 sistema deve

validar se 0CPF informado pelo c1iente e verdadeiro. Por

tras do evento "inserir novo c1iente", 0 sistema devera

executar uma opera<;ao para satisfazer 0even to gerado,

podendo ser uma opera<;ao chamada ValidarCPF ().

Utilize-se dos diagram as de intera<;ao para mostrar como

os objetos colaboram entre si para a realiza<;ao dos

cornportamentos identif icados na analise de casos de uso.

Caracterf sticas dos diagramas de intera<;ao:

• Representam a dinamica entre os objetos, para

realizarem comportarnentos descobertos a partir dos

casos de uso.

• Representam as colabora<;6es entre objetos para cada

comportamento de urn sistema.

Of erece simplicidade de visualiza<;ao, pois as

colabora<;6es entre os objetos acontecem por meio da

troca de mensagens, que podem ser vistas se foremobservados os diagramas.

• Disponibiliza dois tipos de diagramas para

representarem as intera<;6es de urn sistema.

Os diagram as d e seqiiencia dao enfase a ordena<;ao

seqUencial em que os comportamentos acontecem,

enquanto os diagramas de colabor at ;ao dao enfase aordena<;ao estrutural dos objetos que colaboram entre si.




Diagrama de sequencia versus diagrama de

colaboral;ao

o diagrama de seqUencia e 0diagram a de colabora<;ao

mostram os mesmos aspectos de urn modelo, apenas

diferenciando como essas informa<;6es saG projetadas.

Isso querdizerque os doisdiagramas saGsemanticamente

equivalentes, podendo usar urn ou 0outro para visualizar

modelos sob uma perspectiva dinamica.

/ ObJetO$~

I QlliJti I I ~

As linhas verticais nos diagramas de seqUenciasaGchamadas

de linha de vida, e representam a vida do objeto durante umaintera<;ao(por isso, ha uma Iinha para cada objeto).

o foco de controle tern urn importante papel nos diagramas

de seqUencia, indicando 0perfodo de dura<;aopelo qual os

objetos esmo cooperando para realizar urn comportamento.

Mensagem

Uma me(sagem e representada por uma fIecha entre dois

objetos. A mensagem e representada na posi<;aohorizontalentre as Iinhas de vida dos objetos, e sua ordem edemon strada de cima para baixo no diagrama.

Uma condi~iio indica quando uma mensagem e enviada

a urn objeto, desde que essa condi<;ao seja verdadeira.

Urn marcador de intera~ao demonstra quantas vezes

uma mensagem e enviada a urn objeto. Isso se torna util

quando queremos demonstrar urn processamento em que

hli mais de uma informa<;ao a ser processada. Pode ser

demon strada com urn asterisco (*).

Uma mensagem de retorno indica 0 retorno de uma

mensagem, e nao uma nova mensagem. Se necessario,

voce pode representar urn retorno para cad a mensagemenviada aos objetos. Utilize esses retornos quando 0

resultado de uma mensagem nao ficar claro para quem

estiver lendo 0 diagrama de seqUencia. Em diagramas de

seqUencia em que hli muitos objetos colaborando, as

mensagens de retorno pod em confundir 0 leitor por

deixar 0 diagrama muito polufdo graficamente.

Para urn cadastramento simples de c1ientes, poderfamos

ter 0seguinte diagrama de seqUencia:

: W;UCPFO

~

S,tv"Q

If---~

"l1,mEIl'hIiOOI:

II




Diagrama de colaborac;ao

Apesar dos diagramas de intera<;ao serem semanticamente

equivalentes, ha dif eren<;as na forma de como as

informa<;6es saG organizadas em cada urn. No diagrama

de colabora<;ao, os objetos seguem uma ordem estrutural,

onde sao representados par fcones.

1:Sal Var()

Ent@da de urn ---:;;:.

~

2: Va lida rC PFO

n"'Ite m referencia)

!3:SCllv atO

As mensagens nesse diagrama sao semelhantes as do

diagrama de seqUencia. A autodelegar ;ao e representada

par urn arco e tern 0mesmo prop6sito da autochamada

nos diagram as de seqUencia.

Urn objeto e uma manisfesta<;ao concreta de alguma

abstra<;ao (classe). Urn objeto e a "invoca<;ao" de sua

abstra<;ao para seu ef etivo uso, ou seja, urn objeto e a

instancia de uma classe. Instancia e objeto tern 0mesmo

significado, podendo ser usado qualquer urn dos termos.

Uma abstra<;ao e algo que existe apenas ideal mente, ou

seja, nao e algo materializado. Ja os objetos representam

as abstra<;6es materializadas.

Na UML e possfvel representar e diferenciar esses dois

artefatos~

II

o nome de urn objeto e representado como - nome do

objet o: nome d a classe.

Voce representara nos diagramas de intera<;ao nao asclasses, mas sim as instancias de classes (objetos). Como

o objetivo dos diagramas de intera<;ao e demonstrar 0

momenta de intera<;ao dos objetos em resposta a algum

evento, f az muito sentido a representa<;ao de instancias

de classes.

Os diagramas de intera<;ao alem de serem apropriados

para a modelagem dinamica de urn sistema, apresentam

como principal foco a realiza<;ao dos casos de uso.

Com esses diagramas e possf vel e recomendado que sefa<;aa realiza<;aodos casos de uso, par meio da colabora<;ao

entre os objetos do sistema que interagirao entre si para

que esses comportamentos sejam satisfeitos.

Exemplo da realiza<;ao dos comportamentos do caso de

uso mantemClientes

Comportamentos identificados:

O b j e to s d o c a s o d e u s o C a r a c te r f st ic a

Va lida ra c idade C om p ortam e ntodese jadoVal idar 0 C P F C om p o rtam e n todese jadoInclu i rum n ovo c1 ie n te C om p o rtam en todese jado

:aalnc:lulrumn owcHente:

:~~Jepro

i Recup en. 'O :r---~ j(id,d.Eneonl.rad~1 :

, Sa••••.1() :

i "0! :~ltmConIa3anean;l1 :

: SMtO:




Auxflio aos desenvolvedores

Todos os diagramas disponf veis pel a UML devem ser

usados como fonte de infonna~6es para 0desenvolvimento

de urn sistema.

Os diagramas de casos de usa, por exemplo, podem ser

usados em todas as etapas da constru~ao do sistema,

desde a def ini~ao da arquitetura ate a etapa de testes.

Os diagramas de classes podem servir de auxflio para

visualizar 0esqueleto de urn sistema, e como 0sistema

deve ser construfdo em rela~ao a sua arquitetura. Todos

os diagramas disponf veis pel a UML sao pe~as

fundamentais no desenvolvimento de urn sistema.

Osdiagramas de intera~ao demons tram os eventos gerados

pelos atores no sistema, e as opera~6es em resposta a

esses eventos. Por isso, se observarmos os diagramas de

intera~ao mais a fundo, podemos perceber maisinforma~6es do que inicialmente parece.

Podemos visualizar:

• Todos os passos para determinado cemirio de urn

sistema.

• Todos os objetos utilizados em resposta a cad a evento

gerado no sistema.

• A l6gica utilizada para responder a cada evento, por

meio das colabora~6es entre os objetos utilizados

nesse processo.

• As opera~6es utilizadas em cada evento e a importanciaque cada uma exerce no processo como urn todo.

Recomenda-se 0usa dos diagram as de intera~ao tambem

na fase de constru~ao de urn sistema, pois nesses diagrarnas

sao demonstrados todos os objetos trabalhando para

atender as necessidades do sistema. Indo mais alem, toda

a l6gica de como os objetos devem trabalhar para atender

aos eventos gerados estao demonstrados nesses diagramas.

Portanto, se voce e urn desenvolvedor de sistemas, fa~a

usa desses diagramas para facilitar seu trabalho. Se voce

nao e urn desenvolvedor de sistemas, indique ou fa~a comque seus desenvolvedores se utilizem desses diagramas.

Para a modelagem dos diagramas d e intera~iio:

• Defina 0caso de usa que voce deseja realizar por meio

dos diagramas de intera~ao.

• Def ina quais serao os comportarnentos do respectivo

caso de usa que voce expressani pelos diagrarnas de

interac;:ao.Caso todos os comportamentos do caso de

usa que voce esta expressando f iquem rnuito confusosem urn unico diagrama, separe essa rnodelagem em

mais de urn diagrarna, nomeando-os com umareferencia

ao diagrarna principal.

• Nos diagramas de seqUencia, para cada evento gerado,

mantenha apenas urn f oco de controle, com a intenc;:ao

de deixar claro para 0 leitor do diagrama quais sao as

colabora~6es existentes entre os objetos em res posta

ao respectivo evento representado.

• Crie notas para seus diagramas de interac;:aoa fim de

deixa-los mais infonnativos e completos.



o diagrama de graficos de estados representa os estados

possfveis de urn objeto em particular. Isso quer dizer que

serao demonstrados os eventos possfveis para somente

urn objeto individual e as a~6es tomadas pOl'esse objeto

em resposta a esses eventos.

o diagrama de graficos de estados representa as

ocorrencias de eventos,bem como as atividades que devemocorrer ao longo da vida de urn objeto. As atividades

executadas pelo objeto resultam em a~6es que podem ou

nao mudar 0 estado atual de urn objeto. Portanto, crie

diagramas de gnificos de estados para as classes e os casos

de usa de urn sistema.

Caracterfsticas dos diagramas de gnificos de estados:

• Demonstra os estados possfveis para urn objeto em

particular.

• Demonstra pOl' meio das transi~6es, os eventos que

geram a mudan~a de estado de urn objeto.

• Ajuda no entendimento de processos complexos, que

casos de uso e classes passarn durante a execu~ao de

urn sistema.

Os estados tambern model am a dinamica de urn sistema.

Urn estado e urna situa~ao vivida pelo objeto pelo qual

esse objeto deve responder algo aos eventos gerados.

Portanto, urn estado e a condi~ao de urn objeto em algurn

momenta em que 0 objeto esta sendo usado no sistema.

Dica: crie diagramas de gnificos de estados

para as classes e os casos de uso mais

complexos, desde que os estados nao estejam

tao claros. Os diagrarnas de intera~ao cumprem

geralrnente 0papel de retratar os estados dos

objetos pormeio das mensagens trocadas entre

eles em resposta a cada even to. E claro que ha

diferen~as entre os diagramas de intera~ao e os

diagram as de grafico de estados. 0 primeiro

demonstra as colabora~6es entre objetos em

resposta a eventos, 0 segundo demonstra os

eventos e os estados para urn objeto em

particular, apos a ocorrencia das atividades

criadas a partir dos eventos gerados para 0

objeto.

II


Urn evento e uma ocorrencia de urn estfrnulo gerado para

o objeto, capaz de f azer a mudan~a de seu estado atual.

Transic;ao

Uma transir;iio e urn relacionamento entre dois estados,

em que 0objeto em seu estado atual deve realizar atividades

para passar para urn outro estado, desde que as atividadestenharn sido cumpridas.

Pela figura apresentada podemos observar duas nota~6es

que representam 0 estado inicial e 0 estado final de urn

objeto. 0 estado inicial representa 0infcio do estado do

objeto. E representado pOl'urn cfrculo preto preenchido.

o estado final representa 0 termino dos estados de urn

objeto. E representado pOl' urn cfrculo preto preen chido

com urn outro cfrculo em bran co a sua volta.

Em seguida, podemos observar os dois estados possfveis

para 0 objeto larnpada, 0 estado d esligada e 0 estado

acesa. Urn estado e representado pOl' urn retangulo com

pontas arrendondadas.

Entre os estados temos urn relacionamento, responsavel

pOl' ilustrar a passagem de urn estado para outro, que

chamarnos de transi~ao.

Retornando aos exemplos dados anteriormente, vamos

analisar os estados do objeto AnaliseCredito (objeto

criado agora para darmos 0 exemplo) no contexto da

analise de credito das propostas de financiamento.

II



Como podemos ver na figura a seguir, uma amllise de

credito inicia com urn estado que chamamos de Analis

Pend ente. Seguindo a seqUencia dos eventos, apos ess~

estado inicial 0 objeto passa para 0 estado Propost a

Analisada (repare que os estados seguem uma seqUenci

de eventos que fazem sentido se analisarmos todo

contexto do processo). Apos 0estado Pr o posta Analisad a.

o objeto pode assumir 0estado Analise Re provada ou

estado Analise Aprovada , de acordo com a condic;:aoexplfcita nas mensagens enviadas a esses estados.

Como fazer

• Defina 0tipo de contexto a ser abordado nos diagramas

de gnificos de estados - classes ou casos de uso.• Defina quais serao os eventos importantes do objeto a

serem representados.

• Estabelec;:a0estado inicial e 0estado final do objeto.

• Estabelec;:aos estados para 0objeto e, se posslvel, em

ordem sequencial, os eventos e suas respectivas

transic;:oesque ligarao urn estado a outro.

o diagrama de ati vidades representa urn fluxo de controle

de atividades, que ocorrem no processo de urn sistema,oferecendo suporte para comportamentos condicionais e

paralelos.


Com 0diagrama de atividades e posslvel tambem fazer a

modelagem do fluxo de atividades de urn objeto especffico,

por meio das transic;:oes de estados que urn objeto sofre

durante sua existencia.

1 - ' 0 1 " ', Pedidod llAn :.liu ' \ ~-A!iYII:bd9

/~~)• d" Cr idi lo

(RiCUPirildadosdo

'- cU & nta'-

I :=1 /0...'IC omp ativ ilj , ~Inntol

0 / ,!

/ aprcuaranibe) / llplll'f UJnii$ld.

\ dannd3, (l'!I"Ida

. L

:u:,I.

Ao contnirio dos outros diagram as existentes na UML, 0

diagrama de atividades nao tern origem nos trabalhos de

Booch, Rumbaugh e Jacobson. 0 diagrama de atividades

teve sua origem e outras tecnicas, como : diagramas de

eventos de Jim Odell, modelagem de estados SDL,

modelagem de workflow e redes de Petri. Esses diagramasapresentam principalmente a descric;:ao de

comportamentos por meio de processamento paralelo.




Atividade

Uma ativid ad e e urn estado de execuc,:aode alguma coisa.

Pode ser, pOl'exemplo, a execuc,:aode urn metodo em urn::.

c1asse, uma rotina de trabalho, etc.

Uma se para~ao e usada para exibir comportamento:

paralelos, que apresenta uma transic,:aode entrada podendo

tervarias outras transic,:oesnasafda. Quando esses thread s

de entrada sac acionados, as transic,:oes de safda sao

processadas em paralelo. No exemplo do processo d

analise de credito, 0calculo do credi tscore e a recuperac,:ao

e analise da renda do c1iente ocorrem em paralelo.

Uma jun~ao eusada para exibir comportamentos pat'alelo .

ou seja, 0objetivo e unir em uma unica safda os thread s

iniciados pOl' uma separac,:ao.

Urn d esvio e uma transic,:aode uma unica entrada, em que

ha varias transic,:oes de safda. Urn desvio e urn tipo de

comportamento Condiciorial.

Uma intercala~ao e urn comportamento condicional em

que himuitas transic,:oesde entrada e uma unica transic,:ao

de safda.

Marca 0fim das atividades no diagrama.

Caracterfsticas do diagrama de atividades:

• Demonstra as atividades que ocorrem para urn processo

especffico do sistema.

• Pode ser utilizado para representar os passos de urn

cenario descrito pOl'meio de caso de use, para f acilitar

seu entendimento.


No diagrama de atividades - Analise de credito - ap6s a

recuperac,:aodos dados do c1iente, e acionada uma transic,:ao

de entrada em que ha duas safdas concorrentes, ou seja, as

saf das sac comportamentos paralelos. Chamamos esse

comportamento de separa~ao. Ap6s serem efetuadas as

atividades Calcular cr ed it scor e e Recu perar renda d o

cliente, ocorre a atividade C omparar Polit ica de Cred it o.

Esse tipo de comportamento chamamos de jun~ao (une

as transic,:oes iniciadas pel a separac,:ao).

Ajunc,:aoimpoe umaregra no quedizrespeito as atividades

que esta recebe. Todas as atividades recebidas pOl'uma

junc,:aodevem ser completadas (f inalizadas) para que esta

ocorra.

Uma excec,:aoa regra dajunc,:ao e 0thread que sai de uma

separac,:ao, e que depende de uma condic,:ao para ser

finalizado. Chamamos essa condic,:ao de t hread

condicional. Esse thread condicional diz no diagrama

que, se a condic,:ao for falsa, esse thread pode serconsiderado como finalizado.

No exemplo a seguir, e demonstrado urn diagrama de

atividades na preparac,:ao de urn bolo. Mesmo que eu nao

goste de baunilha, os ingredientes serao misturados.

IIS e gostar de bau nilha j

II



Costuma-se dizer que diagramas de atividades saa

variar;6es ou casos especiais de diagramas de gnif icos de

estados. Isso f az muito sentido, pois a maioria dos estadas

sac estados de ati vidades, e as transir;6es sac acionadas se

f orem finalizadas as transir;6es de origem.

Voce pode demonstrar atividades que se repetem por

meio de concorr encia dinamica. Uma concorrenciadin arnica indica que uma atividade deve ser executada em

urn ciclo (loop), ate seu termino. Utilizando esse meio,

voce nao precisa demonstrar a atividade dentro de urn

cicIo de execur;ao. A concorrencia dinamica e expressa

por urn marcador de multiplicidad~ (*), indicando a

repetir;ao da mesma atividade mais de uma vez.

A seguir, urn exemplo da execur;ao de uma atividade com

uma concorrencia dinamica:

P r e e n ch e r lis t a d ep ropos tas .. , C onco rr enc ia

din f un ica

II

V ma raia d e natac;tioorganiza as atividades representadas

em diagramas. Essa organizar;ao consiste em criar grupos

que sac respons3veis pelas atividades que ocorrem nos

diagramas de atividades.

Urn diagrama de atividades informa as atividades que

ocorrem dentro de urn processo, mas nao diz quem sac os

respons3veis por essas atividades. Voce deve utilizar as

raias de natar;ao caso queira nomear os respons3veis por

urn grupo ou par atividade, podendo inclusive informar,

se for 0caso, as classes que serao respons3veis por essas

atividades.

Vma raia de natar;ao e f ormada por zonas verticais

delimitadas por linhas.

A seguir, urn exemplo de raias de natar;ao demonstrando

a responsabilidade de cada classe sobre as atividades em

execur;ao:

Exemplo com algumas atividades do diagrama Analise de credito

utilizando raias de natac;:ao

II




Diagrama de atividades versus diagramas de

intera«;ao

Quando voce usar as raias de nata<;:aoem diagramas de

atividades, estani fazendo a atribui<;:ao de

responsabilidades para as atividades em execu<;:ao.Esse

tipo de nota<;:ao e semelhante as descri<;:6es de

responsabilidades nos diagramas de intera<;:ao.A diferen<;:a

e que em diagramas de intera<;:ao,sac demonstradas as

intera<;:6esde objetos, 0que nao acontece com os diagramasde atividades.

Como fazer

• Identifique os cemirios que voce deseja representar por

meio do diagrama de atividades.

• Inicie a modelagem apenas com as atividades basicas,

acrescentando ao longo da modelagem separa<;:6ese

jun<;:6es,desvios e intercala<;:6es, e outras nota<;:6esse

necessario.

• Se necessario, tambem organize 0 diagrama de

atividades com raias de nata<;:ao.Essa e uma 6timaop<;:aopara se visualizar as responsabilidades sobre as

atividades em execu<;:ao.

II

o diagrama de com ponentes representa os componentes

que faraDparte dos sistemas em constru<;:ao,demonstrando

as dependencias entre esses componentes.

Todo 0sistema orientado a objetos tera, dependendo do

tamanho, dezenas ou centenas de componentes que em

conjunto darao sentido a todos os processos de neg6cios

desse sistema.

Poderao existir componentes responsaveis pela

irnplementa<;:ao de uma ou mais classes, mas podera, e

com certeza existirao, outros tipos decomponentes, como

tabelas, documentos, arquivos executaveis e tudo que

compora fisicamente 0 sistema. Esses outros tipos de

componentes de sistemas podem e devem ser

representados nos diagramas de componentes.

Caracteristicas do diagrama de componentes:

• Demonstra os componentes de urn sistema, com as

dependencias entre eles.

• Podem serrepresentados componentes do tipo arquivo,

documentos, tabelas, bibliotecas, entre outros artefatos

de ur n sistema.

Voce podera empregar os diagramas de componentes

em dois tipos de modelagem:

• Fontes de sistemas.

• Vers6es de sistemas.




Fontes de sistemas

Voce podeni utilizar m ; diagramas de componentes para

fazer a modelagem dos c6digos-fonte de urn sistema.

Dessa forma, voce teni especificado e documentado a

estrutura de componentes utilizados no constru<;ao do

sistema.

Voce podera utilizar os diagramas de componentes para

fazer a modelagem das vers6es liberadas dos sistemas

que serao construfdos. Uma versao de urn sistema

geralmente e composto por urn conjunto de componentes

e outros arquivos que serao entregues aos seus usuarios.

Urn componente e uma implementa<;ao ffsica das

abstra<;6esdescobertas pelos diagramas de classes. Assim

como as classes saD os blocos de constru<;ao mais

importantes nos sistemas orientados a objetos, oscomponentes podem ser considerados implementa<;6es

ffsicas desses blocos de constru<;ao.

Urn modelo e algo que se pretende reproduzir. as

componentes saD essas pr6prias reprodu<;6es, nao

abstratas, mas ffsicas e executaveis, com 0objetivo de se

adaptar e realizar interfaces.

II

Uma interface e urn conjunto de opera<;6es que definem

os servi<;osde uma classe e/ou componente. Uma interface

pode definir, de forma total ou parcial, os servi<;os que

serao utilizados ou fomecidos por urn componente.

Graficamente, uma interface e representada por um cfrculo

e, em sua forma expandida, por uma classe estereotipada

como « Interface».

«Interface»·Q ueu e

«In terface»W or ker

«S ~ t> > DefaultC a llB<ick O ·"<Get» .Defau ltCa liBackO

GelE veri lObjectOA ddO

«S e t» Q u eu eM g rR ef Q«Let»LogO .

« Ge t» L og O«.Le l~ .>ID O ··· ···

,Validacoas. java ~ ~

.__ .._ .._ . _ _ ._-~

Voce pode representar nos sistemas que construira nao s6

os componentes que deverao interagir com as interfaces

definidas, mas tambem todos os tipos de artefatos que

faraDparte do sistema. Esses artefatos podem ser arqui vos

executaveis, tabelas, biblioteca, documentos, arquivos

HTML, etc.




Tambem e possfvel definir estereotipos para classificaros

componentes de sistemas.

«Bibliolecas»

c1ientes.dll

«Bibliotecas»

avalista.dll

Sistemas baseados em componentes

Ao contnirio de outros tipos de implementa~6es, os

sistemas baseados em componentes podem trazerdiversos

beneffcios. Urn deles e a modularidade.

Em outros tipos de implementa~6es, urn sistema e

construfdo em programas, engessando todo 0processo dosistema. Quando urn sistema e construfdo em componentes

isso nao acontece, pois esses componentes podem ser

substitufdos, alterados e reutilizados indi vidualmente,

sem comprometer outras partes do sistema ..

a beneffcio nessa estruturae muito claro. Paraincluirmos

mais funcionalidades aos sistemas, basta construirmos ou

reutilizarmos componentes que forne~am os servi~os

necessarios a nova implementa~ao. Dessa forma,

construiremos sistemas com maior produtividade e

qualidade, pois faremos apenas componentes que

oferecerao servi~os ainda nao existentes no sistema.

Como fazer

• Identifique os componentes que farao parte de seu

sistema.

• Utilize estereotipos se necessano, para especificar

melhoros componentes que voce utilizara no diagrama

de componentes.

• Identifiqueas interfaces de sistemas que serao utilizadas

e disponibilizadas pelos componentes, para ilustrar

seu diagrama.

• Coloque no diagrama de componentes os documentos,tabelas, arquivos, que fazem parte de seu sistema.

a diagrama de implanta~ao representa a configura~ao e a

arquitetura de urn sistema em que estarao ligados seus

respectivos componentes, podendo ser representado

tambem a arquitetura ffsica de hardwares, processadores,

etc. a diagrama de implanta~ao abrange a visao estatica

de implantac;:ao de urn sistema, envolvendo a modelagem

da topologia de hardware em que 0sistema sera executado.

Caracterfsticas do diagrama de implanta~ao :

• Pode representar a estrutura da plataforma em que 0

sistema sera executado.

• Po de representar qualquer dispositivo, como

gerenciador de banco de dados, servidores,

computadores, etc.

a foco dado nesse diagrama nao sera destinado aos

desenvolvedores do sistema. Esse ctiagrama destina-se a

profissionais, como, porexemplo, engenheiros de sistemas

ou analistas de suporte, que devem estar preocupados

com 0hardware e 0software que esta sendo construfdo,

destacando principalmente a compatibilidade entre os

dois.

Como ja foi dito anteriormente, a UML e uma linguagem

para visualiza~ao, constru~ao, especifica~ao e

documenta~ao de artefatos de sistemas de software, mas

tambem pode abranger artefatos de hardware. Isso nao

quer dizer que a UML e uma linguagem com urn objetivo

amplo para a descri~ao de hardware. A UML vai ate 0

limite no que diz respeito a plataforma em que 0sistema

em desenvolvimento sera executadb.




Uso comum

o diagrama de implementa<;ao nao devera ser utilizado

para todos os tipos de sistemas. Por exemplo, se voce esta

desenvolvendo urn sistema simples que sera executado

em apenas uma maquina, em que nao ha participa<;ao de

outros tipos de hardware que interagem enquanto 0sistema

e executado, 0 uso do diagrama de implanta<;ao nao vai

ser muito uti!.

Em vez disso, utilize 0 diagrama de implanta<;ao para

fazer 0mapeamento de hardwares cujo sistema interagini

com mais de uma maquina de diferentes processadores,

servidores, banco de dados, etc.

Como fazer

• Identifique os dispositivos e processadores para 0

sistema que esta desenvolvendo.

• Se for possivel, fa<;a uso de ferramentas para a

descoberta da topologia de hardware onde 0sistema

sera executado.

• Se necessario crie mais de urn diagrama de implanta<;ao,

cada urn focalizado em aspectos especfficos de sua

estrutura de hardware.

• Para os diagramas de implanta<;ao, voce tambem pode

utilizar notas para informar melhor 0leitor sobre esses

diagramas, bem como chamar a aten<;aopara aspectos

importantes.

Se voce fez a leitura desse guia desde 0infcio,

ja deve ter entendido 0 motivo pelo qual a

UML foi estabelecida como padrao pela

industria de software. A UML, dentro de urnciclo de desenvolvimento, abrange todos os

aspectos, que vaGdesde 0levantamento inicial

do sistema (onde nao se tern nada ainda),

passando pela modelagem da arquitetura dos

objetos que formarao esse sistema, ate 0

mapeamento da estrutura de hardware em que

esse sistema sera executado.

A UML e uma linguagem-padrao para a modelagem de

sistemas orientados a objetos. Apesar de sua padroniza<;ao

predefinida, a UML oferece nota<;6es de extensao que

permitem a amplia<;ao de como podemos expressar nossos

modelos. Basicamente, podemos encontrar duas formas

de extensao da UML:

• Estere6tipos.

• Restri<;6es.

Estere6tipos

Os estere6tipos sac utilizados para a classifica<;ao de

novos elementos na UML. 0 estere6tipo e utilizado para

a cria<;ao de classifica<;6es de elementos que nao foram

definidos como padrao, e deve ser utilizado para 0

tratamento de problemas especfficos de modelagem. Os

estere6tipos sac formados por palavras entre fmgulos

duplos "«estereotipo »". Segue uma lista de

estere6tipos predefinidos, que foram extraidos a partir do

uso comum destes. Essa lista segue a seguinte classif ica<;ao:

• Estere6tipos para relacionamentos de dependencias.

• Estere6tipos para classes.

• Estere6tipos para eventos e mensagens.

• Estere6tipos para componentes.

• Estere6tipos para relacionamentos de generaliza<;ao.

• Estere6tipos para restri<;6es.

• Estere6tipos para comentarios.

Estere6tipos para relacionamentos dedependencias

Especifica que 0 conteudo publico do pacote de destine

esta acessivel ao espa<;o do nome do pacote de origem.

Especifica que a origem instancia 0template de destino,

utilizando os parametros reais dados.

Especifica que a opera<;ao de origem invoca a opera<;aode

destino.

II




«derived»

Especifica queo elemento-origem e deri vado do elemento-

destino. Isso significa que 0elemento-origem nao e uma

instancia do elemento-destino, mas e uma instancia de urn

outro elemento que e urn subtipo ou uma subclasse do

elemento-destino.

Especifica que urn caso de uso tern urn comportamentoestendido a partir de urn caso de uso-base.

Especifica que 0 elemento-origem tern visibilidade

especial no elemento destino.

«import»

Especifica que 0 conteudo publico do pacote-destino

pode ser recebido e acessado por urn pacote-origem.

«include»

Especifica que comportamentos comuns a mais de urn

caso de uso devem ser captura em outro caso de uso que

sera utilizado pelos casos de uso que the deram origem.

«instanceof»

Especifica que 0 objeto de origem e uma instancia do

classificador de destino.

Especifica que as opera<;6es na classe de origem criam

instancias da classe de destino.

Especifica que a origem e urn grau mais alto de abstra<;ao

que 0destino.

«send»

Especifica que a opera<;ao de origem envia 0 evento

destino.

Especifica que 0 destino e urn antecessor hist6rico da

origem.


Estere6tipos para classes

Especifica urn elemento que interage externamente com

o sistema.

«exception»

Especifica urn evento que po de ser ativado ou capturado

por uma opera<;ao de classe.

«implementationC lass»

Especifica a implementa<;ao de uma classe em uma

linguagem de programa<;ao.

«interface»

Cole<;ao de opera<;6es que pode ser utilizado para definir

os servi<;os que uma classe pode oferecer a outras.

Especif ica urn classificadorcujas instancias de suas classes

estaoenvolvidas em urn relacionamento de generaliza<;ao.

Especif ica urn classificador cujas instancias representam

urn fluxo pesado.

«signal»

Especif ica urn estfmulo assf ncrono comunicado entre

instancias.

«stereotype»

Especifica que 0classificador e urn estere6tipo que podeser aplicado a outros elementos.

Especifica urn classificador cujas instancias representam

urn fluxo leve.

Especifica uma classe abstrata que e utilizada somente

para determinar a estrutura e 0 comportamento de urn

conjunto de objetos.

II




«utility»

Especifica classes cujos atributos e opera90es saD todo

escopo de classes.

Estere6tipos para eventos e mensagens

«becomes»

Especifica que0

objeto-destino e0

mesmo objeto que0

de origem, mas em urn ponto adiante no tempo e com

possiveis valores, estados ou papeis diferentes.

Especifica que 0 objeto de destino e uma c6pia exata do

objeto-origem, mas e independente.

Especifica que 0objeto-destino e criado pelo evento ou

pela mensagem enviada pelo objeto-origem.

«destroy»

Especifica que 0 objeto-destino e destrufdo pelo evento

ou pela mensagem enviada pelo objeto-origem.

Estere6tipos para componentes

<<table»

Especifica urn componente que representa uma tabela de

banco de dados no sistema.

Especifica urn componente que representa urn documentodo sistema.

Especifica urn componente que representa urn componente

que poden! ser executado no sistema.

«file»

Especifica urn componente que representa c6digos-fonte

ou dados.

Especifica urn componente que representa uma bibliotec!l

de objetos.


Estere6tipos para relacionamentos de

generalizac;ao

«implementation»

Especifica que 0filho herd a a implementa9ao do pai, mas

nao a toma publica, nem oferece suporte para suas

interfaces, violando dessa forma a caracteristicade permitir

substitui90es.

Especifica uma restri9ao que sempre precisa ser mantida

para 0 elemento que esta associado.

«precondition»

Especifica uma condi9ao que deve ser verdadeira antes da

invoca9ao de uma opera9ao.

«poscondition»

Especifica uma condi9ao que deve ser verdadeira ap6s 0

termino da execu9ao de uma opera9ao.

Estere6tipos para comentarios

«requirement»

Especifica uma caracteristica ou comportamento desejado

para urn sistema.

«responsability»

Responsabilidade ou obriga90es que urn elemento e

encarregado de cumprir.




Restriyoes

As restri~oes ampliam 0 vocabuhlrio dos elementos n

UML, permitindo modificar ou acrescentar novas regras

aos elementos do modelo. Por exemplo, por uma questiio

de regra de neg6cio, todos os clientes do tipo pessoa ff sica

devem ter obrigatoriamente 0salario informado. Podemo

expressar essa restri~ao como no exemplo a seguir. A

regras devem ser express a entre chaves {}.

PessoaFisica

data Nascimento

sexoRG

C P F

salarioestadoCivil

A UML tambem define como padrao algumas restri~oes.

Aqui segue uma lista com esses padroes com 0elemento

a qual se aplica.

Restriyoes para generalizayao

{complete}

Especifica que todos os subtipos de urn supertipo ja foramespecificados, nao permitindo filhos adicionais.

Especifica que nem todos os subtipos de urn supertipo

foram total mente especificados, permitindo filhos

adicionais.

Especifica que subtipos de urn supertipo podem ter mais

de urn filho como tipo.


Restriyoes para instancias

{destroyed}

Especifica que a instancia deve ser destrufda antes da

conclusao da intera~ao da qual ela faz parte.

Especifica que a instancia deve ser criada durante a

execu~ao da intera~ao da qual ela faz parte.

Especifica que a instancia deve ser criada durante a

execu~ao da intera~ao daqual elafaz parte, mas e destrufda

antes da conclusao da execu~ao.

A UML, alem de disponibilizar nota~oes para restri~oes

diversas, apresenta uma linguagem mais formal para a

expressao de restri~oes e condi~oes, chamada DCL.

Mais informa~oes sobre a DCL, consulte :



Ferramentas que suportam a UML

Desde 0 lan~amento da UML no mercado, houve por

parte de algumas empresas da area de informlitica a

percep~ao da oportunidade de construirem ferramentas

que suportassem essa nova tecnologia. A seguir 0 leitor

encontrara algumas ferramentas disponiveis no mercado

que suportam a linguagem UML.

Essa ferramenta foi des en vol vida pela Rational Software.

Considero-a a mais completa disponivel ate 0momenta

no mercado. E uma ferramenta totalmente focada para a

linguagem UML, mas tambem oferece suporte para os

metodos Booch e OMT.

Essa ferramenta foi desenvolvida pela MicrosoftCorporation, fazendo parte do pacote Office. Considero-

a uma ferramenta razoavel. Alem de suporte a UML, essa

ferramenta oferece suporte para outros tipos de diagramas

(nao UML) para as mais variadas aplica~6es.

Consulte www.microsoft.comloffice/visio

Essa ferramenta foi desenvolvida pela Sybase. Ainda nao

tive a oportunidade de avaliar os recursos que suportam

a UML, mas tenho informa~6es de que essa ferramenta

suporta somente alguns diagramas da UML, como 0de

casos de uso, de classes e de seqUencia.

Para obter mais informa~6es sobre ferramentas que

suportam a l inguagem UML, acesse 0 site

www.umlbrasil.com.bre clique em "Ferramentas".

II

A seguir serao apresentadas as principais mudan~as

ocorridas durante a evolu~ao da UML ate 0momento.

A UML des de seu nascimento vem passando por mudan~as

em seu conteudo. Como con seqUencia dessas mudan~as

foram criadas vers6es mais maduras e completas. Descrevo

a seguir somente algumas mudan~as (que considero as

mais importantes) que ocorreram durante as vers6es

lan~adas da UML.

As mudan~as mais significativas nesta versao, diz respeito

aos diagramas de classes e diagramas de seqUencia. Na

versao 1.1, as classes podem ser especializadas como

tipos ou como classes de implementar;iio.

Uma classe de implementa~ao e realmente uma classe

programada no ambiente de sof tware. Uma classe

especializada como tipo que pode representar uma

abstra~ao do sistema. Podem ser classes que representam

apenas 0 modelo conceitual do sistema ou, ainda, as

interf aces do sistema.

Portanto, voce pode representar em seu modele de classes

de implementa~ao urn ou mais tipos.

Na versao 1.0 da UML, os retomos em diagram as de

seqUencia eram representados por uma flecha vazada, em

vez de uma flecha cheia. Na versao 1.1, os retomos sac

realizados por meio de uma flecha pontilhada, deixando

mais perceptivel esse tipo de atividade. Sup6e-seque essa

mudan~a foi realizada, pois a diferen~a entre uma flecha

vazadae umacheia era muito suti! e de difici! diferencia~ao.

As mudan~as realizadas da versao 1.1 para a versao 1.2,

foram modifica~6es sutis. Somente na versao 1.3 foram

feitas mudan~as real mente significativas.

http://www.microsoft.comloffice/visio

http://www.umlbrasil.com.bre/

http://www.umlbrasil.com.bre/

http://www.microsoft.comloffice/visio



Na versao 1.1 da UML, haviadois tipos de relacionamentos

entre casos de uso: relacionamento do tipo «uses» e

«extends». Ja na versao 1.3, foram disponibilizados

tres tipos de relacionamentos:

• Include.

• Extends.

• Generalizac;ao.

No relacionamento do tipo «include» (substituindo 0

ate entao «uses») as ati vidades em comum

compartilhadas por alguns casos de uso saGinclufdas em

urn outro caso de uso publico. Por exemplo, em urn

sistema de analise de credito pode ser que tanto 0processo

de aprovac;ao de credito quanta 0processo de reprovac;ao

utilizem as atividades de validar a alc;ada do analista de

credito.

No relacionamento do tipo «extends», as atividades de

urn caso de uso nao obrigat6rias saG estendidas em urn

outro caso de uso. Isso significa que urn comportamento

de caso de uso pode ser desviado apenas em situac;oes

predefinidas no caso de uso estendido.

Por exemplo, em urn processo de analise de credito, 0

credito dos clientes pode ser aprovado automaticamente,

sem que tenha de passar par todas as etapas de analise,

caso sua renda seja cinco vezes 0 valor total do

financiamento. Esse comportamento de aprovac;ao

automatica pode mudartodo 0comportamento do sistema

caso sua condic;ao seja verdadeira.

No relacionamento de generalizar;ao 0 comportamento

comum a mais de urn caso de uso em urn mesmo dom f nio,

ecapturadoem urn supertipo (generalizado). Sendo assim,

esses casos de uso agora considerados subtipos

(especializados) herdam desse supertipo criado 0

comportamento comum a eles mesmos.

Para comportamento condicional, voce pode agora usar a

~tividade de decisao (em forma de losango), para a

mtercalac;ao ou ramificac;ao de comportamentos.

A barra de sincronizac;ao e agora refedda como separac;ao

ou junc;ao. Mas voce nao podera mais acrescentar

condic;oes arbitrarias ~s junc;oes. Deve-se, entao, seguir

regras de combinac;ao para assegurar-se de que separac;aoe junc;ao combinam.

o acionamento duplo nao e mais utilizado. Agora voce

pode utilizar a concorrencia dinamica em uma atividade

usando-se 0asterisco (*). '



abstra~aoCaracterfstica essencial de uma entidade que a diferencia

de todos os outros tipos.

agrega~ao

Tipo de associa<;ao na qual um todo e relacionado com

suas partes (relacionamento todo/parte).

agregada

Classe que representa 0 "todo" no relacionamento deagrega<;ao.

arquitetura

Arquitetura de sistemas e um conjunto de decis6es sobre

artefatos e elementos que formaram 0 sistema. A

arquitetura deve abranger como sera construfdo 0sistema,

seus elementos estruturais e comportamentais, suas

colabora<;6es, etc.

artefato

Conjunto de informa<;6es utilizado ou realizado por um

processo de desenvolvimento de sistemas de software.

assinaturaNome, parfunetrose valores de retomo de uma opera<;ao.

associa~ao

Associa<;ao descreve relacionamentos entre objetos. Cada

associa<;ao tem duas pontas, onde em cada ponta esta

ligado um objeto.

atividade

Estado de execu<;ao de alguma coisa. Pode ser, por

exemplo, a execu<;ao de um metodo em uma classe, uma

rotina de trabalho, etc.

ator

Papel desempenhado por qualquer usuario de um caso de

uso, ou seja, 0ator e quem solicita os servi<;os disponfveis

em casos de uso.

atributo

Atributo e uma propriedade de classe. Representa as

caracterfsticas pr6prias de uma abstra<;ao.

autochamada

Mensagem que um objeto envia para si mesmo.

caracterfstica comportamental

Caracterfstica dinamica de um elemento, como uma

opera<;ao ou um metodo.

II

caracterfstica estrutural

Caracterfstica estrutural (estatica) de um elemento.

cardinalidade

Numero de elementos existentes em um conjunto.

caso de uso

Documento que descreve os cenarios pretendidos para

um sistema, com 0objetivo de atender as necessidades dousuario.

classeAbstra<;ao de um conjunto de objetos que compartilham

os mesmos atributos, opera<;6es e relacionamentos.

colabora~ao

Nome dado a intera<;ao entre duas ou mais classes, com 0

objetivo de fornecer algum comportamento cooperativo.

componente

Parte ffsica de um sistema, que representa elementos

l6gicos para a realiza<;ao de uma ou mais interfaces.

com portamento

Resultados produzidos por eventos e metodos.

composi~ao

Forma de agrega<;ao, em que 0objeto-parte pode pertencer

somente ao objeto-todo. Alem disso, geralmente 0objeto-

todo vive e morre com suas partes, isto e, acontece uma

remo<;ao em cascata

container

Objeto que existe para conter outros objetos e que

proporciona opera<;6es para acessar ou interagir com seuconteudo.

delega~ao

Habilidade de um objeto enviar uma mensagem a um

outro objeto como resposta a uma mensagem recebida.

dependencia

Relacionamento entre dois itens, em que a altera<;ao do

item independente pode alterar a semantica do itemdependente.

destinatario

Objeto que manipula a instancia de uma mensagem

passada pelo objeto emissor.

diagrama

Representa<;ao grafica de um conjunto de elementos do

sistema, que permite a visualiza<;ao do sistema sob

diferentes perspectivas.

II



diagrama de atividades

Representa urn fluxo de controle de atividades, que

ocorrem no processo de urn sistema, oferecendo suporte

para comportamentos condicionais e paralelos

diagrama de casos de uso

Representa urn conjunto de cemirios identificados, que

seja util aos usuarios de urn sistema.

diagrama de classes

Representa 0modelo da estrutura de urn sistema orientado

a objetos, demonstrando as classes, os tipos e os

relacionamentos.

diagrama de colabora9ao

Urn dos diagramas de interac;ao que da enfase a organizac;ao

estrutural dos objetos que colaboram entre si.

diagrama de componentes

Representa os componentes que farao parte dos sistemas

em construc;ao, demonstrando as dependencias entre esses

componentes.

diagrama de gnificos de estados

Representaos estados possfveis deum objeto em particular.

Sao demonstrados os estados de urn objeto, eventos,

transic;6es e atividades.

diagrama de implanta9ao

Representa a configurac;ao e a arquitetura de urn sistema

a que estarao Iigados seus respectivos componentes,

podendo ser representada tambem a arquitetura ffsica de

hard wares, processadores, etc.

diagrama de objetos

Representa a modelagem de instancias das classes de urn

sistema em determinado ponto e momenta de execuc;ao.

diagrama de sequencia

Urn dos diagramas de interac;ao que da enfase a ordenac;ao

sequencial em que os comportamentos acontecem.

encapsulamento

Mecanismo usado para ocultar os dados, a estrutura

intema e os detalhes de implementac;ao de um objeto.

Toda a interac;ao com um conjunto de objetos e feita de

uma interface publica constitufda de operac;6es.

estado

Situac;ao vivida por um objeto, pela qual esse objeto deve

responder algo aos eventos gerados.

II

estere6tipo

Extensao do vocabulario da UML que permite a criac;ao

de novos tipos de blocos de construc;ao, para atender

necessidades especfficas de um modelo.

estimulo

Evento gerado no sistema que necessita de resultados.

evento

Ocorrencia de um estfmulo gerado para 0objeto, capaz de

fazer a mudanc;a de seu estado atual.

exportar

Tomar visfvel urn elemento fora do espac;o do nome que

o contem.

expressao

SeqUencia de caracteres que tem como resultado um

valor.

expressao booleana

Tem como resultado um valor booleano.

filha

Subclasse.

foco de controle

Indicador do perfodo de durac;ao pelo qual os objetos

estao cooperando para realizar um comportamento.

generaliza9ao

E a capacidade de se criar superclasses que encapsulam a

estrutura e 0comportamento comum a varias subclasses.

heran9a

Mecanismo pelo qual elementos mais especfficos

incorporam a estrutura e 0comportamento de elementos

mais gerais.

heran9a multipla

Uma variac;ao da generalizac;ao, em que uma subclasse

pode herdar a estrutura e 0 comportamento de mais de

uma superclasse.

hierarquia de classes

Representa descric;6es das relac;6es de heranc;a entre

classes.

implementa9ao

Realizac;ao concreta do contrato declarado por uma

interface ou a definic;ao de como algo e construfdo ou

computado.

incompleto

Modelagem de um elemento em que faltam certas partes.



instancia

Manisfesta~ao concreta de alguma abstra~ao, uma entidade

a qual urn conjunto de operac,;5es pode ser aplicado e que

tern urn estado para armazenar 0efeito das operac,;5es.

integridade

Relacionamento consistente e apropriado entre dois ou

mais elementos.

OCL (Object Constraint Language)

Linguagem formal utilizada para expressar restri~5es de

efeito livre.

intera930

Conjunto de objetos que interagem por meio da troca demensagens, para a realiza~ao de urn comportamento.

Iinha de vida do objeto

Representa a existencia de urn objeto em uma intera~ao.

m3e

Superclasse.

maquina de estados

SeqUencia de estados pela qual urn objeto passa durante

seu tempo de vida.

mecanismos de extensabilidade

Urn dos mecanismos que permite a extensao da UML demaneira organizada.

objeto

Sinonimo de instancia de classe, sendo uma manifesta~ao

concreta de uma abstra~ao com uma identidade que

encapsula estados e comportamentos.

objeto persistente

Objeto que sobrevive ap6s 0termino de execu~ao de urnprocesso ou urn thread.

objeto transiente

Objeto que sobrevive somente ate 0termino de execu~ao

de urn processo ou urn thread.

opera93o

Procedimento de chamada em urn objeto.

opera93o polim6rfica

Uma mesma operac,;ao que e implementada de maneira

diferente por dois ou mais tipos.

orientado a casos de usoProcesso pelo qual os casos de uso sao utilizados como

artefatos primarios para 0 estabelecimento do

comportamento desejado do sistema, para verificar e

validar a arquitetura de urn sistema.

mensagem

Meio de comunica~ao entre objetos que contem

informa~5es a espera de atividades que acontecerao.

metodo

Implementa~ao de uma opera~ao para uma c1asse.

modele

Simplifica~ao da realidade, criado com a finalidade de

proporcionar uma melhor compreensao do sistema que

sera gerado.

multiplicidade

Indica~ao de quantos objetos podem participar de urn

dado relacionamento.

pacotes

Organizam os modelos criados na UML.

pai

Superclasse.

papel

Comportamento de uma entidade que participa de

determinado contexto no sistema.

n6

Elemento ffsico existente em tempo de execu~ao que

representa urn recurso computacional.

parametro

Especificac,;ao de uma variavel que pode ser alterada,

passada ou retornada.

polimorfismo

Conceito segundo 0qual dois ou mais tipos de objetos

podem responder a mesma mensagem de maneiras

diferentes, usando opera~5es polim6rficas.

p6s-condi93o

Algo que necessita ser verdadeiro ap6s a chamada de uma

operac,;ao.

nota

Representa comentarios, observa~5es e esclarecimentos

que se podem utilizar para qualquer elemento da UML.

II·..



pre-condi9ao

Algo que necessita ser verdadeiro antes da chamada de

uma opera9ao.

privado

Mecanismo de escopo usado para restringir 0acesso a

atributos e opera90es de uma classe, de maneira que

outros objetos nao possa utiliza-Ios.

produto

Artefatos de desenvolvimento, como c6digos, modelos,documenta9ao gerada, etc.

propriedade

Caracterfstica de urn elemento da UML.

publico

Mecanismo de escopo usado para tomar atributos e

opera90es de classes acessfveis a outros objetos.

raia de nata9ao

Organiza as atividades representadas em diagramas de

atividades. Essa organiza9ao consiste em criar grupos

que saG responsaveis pelas atividades ocorridas.

realiza9ao

Relacionamento entre itens, no qual urn item implementa

comportamentos especificados por outros. .

receptor

Objeto ao qual e enviada uma mensagem.

refinamento

Relacionamento que representa a especifica9ao completa

de algo ja especificado em determinado nf vel de detalhe.

relacionamentos

Conexao semantica entre elementos.

responsabilidade

Contrato ou obriga9ao em urn tipo ou de uma classe.

restri9ao

Extensao da semantica de urn elemento da UML,

permitindo criar ou modificar regras ja existentes.

solicita9ao

Especifica9ao de urn estfmulo enviado a urn objeto.

subclasse

Elemento que recebe por heran9a a estrutura e os

comportamentos de uma superclasse.

superclasse

Elemento que con tern a estrutura e 0 comportamento

generalizado de outras classes (as subclasses).

thread

Fluxo leve de controle que pode ser executado

concorrentemente com outros thr eads no mesmo processo.

tipoEstere6tipo de uma classe, utilizado para especificar urn

domfnio de objetos, com as opera90es que podem seraplicadas aos objetos.

transi9aoRelacionamento entre dois estados, em que 0objeto no

seu estado atual deve realizar atividades para passar para

urn outro estado, desde que as atividades tenham sido

cumpridas.

UML (Unified Modeling Language)

Linguagem de modelagem unificada para visualiza9ao,

especifica9ao, constru9ao e documenta9ao de artefatos

de sistemas de software.

valor atribufdo

Extensao das propriedades de urn elemento da UML, que

permite a cria9ao de novas informa90es na especif ica9ao

desse elemento.

versao

Urn conjunto de artefatos de software, relativamente

completos e consistentes que serao entregues.

visaoProje9ao em urn modelo, vista a partir de deterrninada

perspectiva ou ponto de vista, que omite as entidades que

nao saG relevantes para essa visao.

visao dinamica

Aspectos de urn sistema que dao enfase a compartamentos.

visao estatica

Aspectos de urn sistema que dao enfase a estrutura.

visibilidade

Especifica9ao de como uma caracterfstica ou urn

comportamento especificado para uma classe podem ser

vistos par outros objetos de classe.



Obtendo mais informa~oes

o site www.umlbrasil.com.br foi criado pelo autor deste

guia, e e 0primeiro site brasileiro dedicado a linguagem

UML. Nele voce encontrani tudo sobre a UML, orienta~ao

a objetos, linguagens de programa~ao, entre outros

assuntos relacionados com 0 tema.

A seguir, uma amostra do que 0 UMLBrasil oferece:

• Tutoriais

Tutoriais sobre UML, orienta~ao a ob jetos, linguagens

de programa~ao, metodologias, etc.

• Artigos

Artigos sobre 0 uso da UML, Java e orienta~ao a

objetos.

• Noticias

Notfcias sobre 0 mercado, eventos, promo~6es elan~amentos de produtos.

• Livros

Livros sobre UML, orienta~ao a objetos, banco de

dados, metodologias e Iinguagens de programa~ao.

Douglas Marcos da Silva e bacharel em Administra~ao de

Empresas. Atua como Consultor na modelagem deaplica~6es orientadas a objetos utilizando a linguagem

UML, ministrando tambem treinamentos nesta linguagem.

Para duvidas ou sugest6es, envie urn e-mail diretamente

para 0autor:

Aabstra98.o 7

Agrega98.0 22

arquitetura 24, 34Associa98.0 21

atividade 62

Ator 28

atributo 8, 41

Autochamada 53

8blocos de constru98.0 17, 38

Booch 9

Ccaracterfsticas 7

caso de uso 18, 27

Caso de uso de alto nfvel 28

Caso de uso detalhado 28, 30

Classe 7, 18

CoadIYourdon 9

Colabora98.0 18

componentes 19, 67, 68comportamentos 7, 24

composi98.0 22

concorrencia dinamica 64

condi98.0 53

odesvio 62

diagrama de colabora98.0 54

diagrama de atividades 13, 24, 25, 60

diagrama de casos de uso 10, 24, 27

diagrama de classes 13, 24, 38

diagrama de colabora98.o 12

diagrama de componentes 14, 25, 67

diagrama de graficos de estados 12, 58

diagrama de implanta98.o 15, 25, 71

diagrama de objetos 14, 24, 50

diagrama de sequencia 11, 52

diagramas de intera98.o 11, 24, 25, 51, 55, 66

EEspecializa98.0 23

Estados 6, 58

Estere6tipos 73

Estfmulos 6

evento 59

Extens8.o 34

http://www.umlbrasil.com.br/










Ffoco de contraIe 52

GGeneralizagao 22, 32

HHeranga 8

Inclusao 33interagao 19, 51intercalagao 62Interfaces 69

Itensdinamicos 17, 19!tensestciticos 17, 18

J jungao 62

LIinguagensde programagao 40

linhade vida 52

MMciquinade estados 19marcadorde interagao 53mensagem 52

mensagemde retorno 53metoda 46

metodoOMT 9metodoOOSE 9

modelagemvisual 16

Modularidade 6Multiplicidadede associagao 21

NNotas 17, 20

oobjeto 7, 54OMG 10OMT 9

OOSE 9

operagao 8, 42, 46

orientagaoa objetos 6

pPacotes 17, 20Polimorfismo 8p6s-eondigao 45

PowerDesigner 80pre-condigao 44

Rraiade natagao 65Realizagao 23relacionamentos 20, 38Relacionamentosentre casos de uso 32Restrigoes 73, 78Reutizagao 6

Rose 80

5separagao 62

Tthread condicional 63

transigao 59

UUML 10, 16, 17, 24, 40

Vversoes da UML 81visibilidade 43

Visio 80



Rational@the e-development company'"

A Rational Software auxilia as empresas a desenvolver e

implantar software para e-business, e-infrastructure e e-

devices atraves da combina~ao das melhores pniticas,

ferramentas e servi~os de engenharia de software. A

solu~ao de e-development da Rational ajuda as empresas

a criar software mais nipido - Time-to- Market - e aIcan~ar

a qualidade necessaria para satisfazerseus cIientes. Esta

solu~ao unica e integrada simplifica 0 processo de

aquisi~ao, implementa~ao e suporte de uma abrangente

plataforma de desenvolvimento de software, 0que reduz

o custo total de propriedade.

Rational ClearCase@ Family G erenc iam en to de con f i gura~6es .

R a t io n a l C le a rQ u e s jT M a n d R a t io n a l C le a rD D T S T M

G erenc iam en to de m uda n~ a e rastream en to de de fe i tos .

R a t io n a l P u rify ® , R a t io n a l Q u a n tify ® , Rational PureCoverage@

Execu~ao de t es tes de con f iab i lidade .

Rational Requisite Pro @

G erenc iam en to de requ is itos .

Rational Robot G rava~ao de sc r ip t f unc iona l e de pe r fo rm ance .

Rational Rose@ family Po ssu i recursos de m ode lagem e m tem po rea l, casos de use , we b , dadose ap l i ca l i vos .

Rational SoDA@

G era~a o au tom a t izada de docu m en ta~ ao .

Rational TeamTest

Execu~ao de t es t es de f unc i ona l i dade .

Rational TestManager G eren c iam en to de ar te fatos d e tes te.

Rational SiteLoad T e s t e s d e c a r g a e m w e b s i t e s .

Rational QuaJityArchitect

G era~a o au tom a t ica de dr ives e s tubs para tes te un itar io .

Rational Unified Process™ Processo con f igu rave l e adap tave l pa ra qua l que r p r o je t o de so ftwa re



• A UML (Unified Modeling Language) e uma

linguagem para especifica<;ao, documenta<;ao,

visualiza<;ao e desenvolvimento de sistemas

orientados a objetos. Sintetiza os principais

metod os existentes, sendo considerada uma das

linguagens mais expressivas para modelagem de

sistemas orientados a objetos. Por meio de seus

diagramas e possivel representar sistemas de

softwares sob diversas perspectivas de

visualiza<;ao. Facilita a comunica<;ao de todas aspessoas envolvidas no processo de

desenvolvimento de um sistema - gerentes,

coordenadores, analistas, desenvolvedores - por

apresentar um vocabulario de facil entendimento.

• Este guia descreve os conceitos da UML e seus

diagramas. Apresenta exemplos de utiliza<;ao

destes diagramas, demonstrando, de maneira

pratica, como pode ser feita a transi<;ao de um

diagrama para outro.

• Pode ser de utilidade para profissionais que

estejam conhecendo a modelagem de sistemas

orientados a objetos, e para alunos dos cursos de

Ciencias da Computa<;ao, Engenharia de

Software, Processamento de Dados e Analise de

Sistemas que estejam estudando 0 assunto.

uml - guia de consulta rapida (2001)

Documents