A notao UML

1 Introduo

Este apndice apresenta os principais conceitos da UML (Unified Modeling Language) que so utilizados neste livro. No objetivo deste texto a descrio completa de cada conceito, e muitos so apresentados de forma simplificada; os interessados nas descries completas devem consultar [Rumbaugh+99] ou as especificaes oficiais da UML, que podem ser obtidas no stio do OMG (Object Management Group). Por outro lado, utilizam-se aqui algumas convenes de notao que o processo Praxis adota, em situaes nas quais a UML permite o uso de alternativas. Por exemplo, as convenes de descrio textual dos casos de uso no so estipuladas pela UML, mas so aqui includas por estarem intimamente associadas maneira de utilizao dos casos de uso dentro do Praxis.

2
2.1

Modelagem funcional
Atores

Os papis dos usurios de um produto so modelados atravs dos atores (Figura 1). Cada ator representa uma classe de usurios. Os atores modelam os papis e no as pessoas dos usurios; por exemplo, o mesmo usurio fsico pode agir como Gerente, Gestor de Estoque ou Gestor de Compras. Pode-se tambm definir atores no humanos, para modelar outros sistemas que devam interagir com o produto em questo: por exemplo, o Sistema Financeiro.

Caix ei ro

G es tor de Com pras

G es tor de E s toque

G erente

S is tem a Financ eiro

Figura 1 - Exemplos de atores

Caso exista grande nmero de atores, deve-se procurar agrup-los em atores genricos, que representem caractersticas comuns a vrios grupos de usurios de comportamento semelhante em relao ao produto. Atores genricos e especficos so ligados por relacionamentos de herana. Na Figura 2, indica-se que Gerente de Vendas e Gerente de Compras tm alguns aspectos em comum, que so abstrados atravs do ator Gerente.

G er ente

G ere nte de Com pras

G erente de V endas

Figura 2 Herana entre atores

2.2

Casos de uso

Os casos de uso representam funes completas do produto. Um caso de uso realiza um aspecto maior da funcionalidade do produto: deve gerar um ou mais benefcios para o cliente ou os usurios. Na Figura 3 so mostrados os casos de uso que representam a funcionalidade de um produto de informatizao de uma mercearia. O conjunto dos casos de uso cobre toda a funcionalidade do produto, e cada caso de uso representa uma fatia independente de funcionalidade.

G e st o d e U su ri o s

E m i ss o d e N o ta Fi sc a l

G e st o M a n u a l d e E sto q u e

O p er a o de V e n da

Em i sso d e R e l a t rio s

A b e rtu ra d o C a i x a

Fe c h a m e n to d o Ca i xa

G e st o d e Fo rn ec e do re s

G e st o d e M e rca d o ri a s

G e st o d e P e d i d o s d e C o m p ra s

Figura 3 - Casos de uso

2.3 2.3.1

Diagramas de casos de uso Relacionamentos entre atores e casos de uso

Diagramas de casos de uso podem especificar os relacionamentos entre casos de uso e atores (Figura 4). Os relacionamentos indicam a existncia de comunicao entre atores e casos de uso. Um caso de uso pode estar associado a mais de um ator, quando a sua execuo requer a participao de diferentes atores.

A bertura do Caix a

G erente

F ec ham ento do Caix a

Figura 4 - Exemplo de casos de uso de um ator

Normalmente, a comunicao ser representada como ligao sem direo; convenciona-se, nesse caso, que a iniciativa de comunicao parte do ator. Quando a iniciativa parte do caso de uso (por exemplo, alarmes, mensagens, dados enviados para outros sistemas etc.), a comunicao deve ser direcionada para o ator (Figura 5). Nesse exemplo, o caso de uso Gesto Manual de Estoque, acionado pelo ator Gestor de Estoque, envia dados para o Sistema Financeiro.

G es tor de E s toque

G es to M anual de E s toque

S is tem a F inanc eiro

Figura 5 - Caso de uso com mais de um ator

Os diagramas de casos de uso podem ser simplificados por meio da herana entre atores. Neste caso, mostra-se um caso de uso comum aos atores especficos, que se comunicam apenas com o ator genrico (Figura 6). Neste exemplo, tanto o Gerente de Compras quando o Gerente de Vendas podem executar o caso de uso Emisso de relatrios, porque eles so herdeiros (especializaes) de Gerente.

G erente de V endas

G erente

Gerente de C om pras

V enda E m is s o de relatrios

C om pra

Figura 6 Uso de atores genricos

O diagrama de contexto (Figura 7) um diagrama de casos de uso que mostra as interfaces do produto com seu ambiente de aplicao. Os diversos tipos de usurios e outros sistemas com os quais o produto deva interagir so representados por atores situados fora de um retngulo que marca a fronteira do produto.

Caixeiro

Operacao de Venda

Sistema Financeiro

Gestor de Estoque

Gesto Manual de Estoque

Abertura do Caixa

Gesto de Pedidos de Compras

Fechamento do Caixa Gerente

Gesto de Mercadoria

Gesto de Usurios

Gesto de Fornecedores

Gestor de Compras

Emisso de Relatrios

Figura 7 - Diagrama de contexto

2.3.2

Relacionamentos entre casos de uso

Notaes especiais so utilizadas para facilitar a descrio de funcionalidade mais complexa. Entre estas notaes, destacam-se os casos de usos secundrios, que simplificam o comportamento dos casos de uso primrios atravs dos mecanismos de extenso e incluso. No Praxis, casos de uso primrios so aqueles que so invocados por iniciativa direta de um ator; casos de uso secundrios so invocados em um passo de outro caso de uso. Os termos primrio e secundrio, quando referentes a casos de uso, no fazem parte da UML. O caso de uso B estende o caso de uso A quando B representa uma situao opcional ou de exceo, que normalmente no ocorre durante a execuo de A. Essa notao pode ser usada para representar fluxos complexos opcionais ou anormais. O caso de uso estendido referenciado nas precondies do caso de uso extensor. As precondies so a primeira parte dos fluxos dos casos de uso. Na Figura 8, a Emisso de Nota Fiscal uma funcionalidade que pode ser invocada ou no, durante a Operao de Venda.

<<extend>>

Caixeiro

Operao de Venda

Emisso de Nota Fiscal

Figura 8 - Caso de uso de extenso

O caso de uso A inclui o caso de uso B quando B representa uma atividade complexa, comum a vrios casos de uso. Essa notao pode ser usada para representar subfluxos complexos e comuns a vrios casos de uso. O caso de uso includo referenciado no fluxo do caso de uso incluidor. Na Figura 9, Baixa no Estoque representa um comportamento comum a Gesto Manual de Estoquee Operao de Venda.

Gestor de Estoque

Gesto Manual de Estoque <<include>>

Baixa no Estoque <<include>>

Caixeiro

Operao de Venda Figura 9 - Caso de uso de incluso

2.4

Fluxos dos casos de uso

No Praxis, os fluxos dos casos de uso so detalhados por meio de descries textuais. A UML no impe formatos obrigatrios para as descries dos fluxos, mas a forma de descrio textual aqui apresenta semelhante s formas usadas pela maioria dos autores que utilizam os casos de uso. O detalhamento dos fluxos dos casos inclui as suas precondies, ou seja, as condies que supem estejam satisfeitas, ao iniciar a execuo de um caso de uso (Tabela 1); o fluxo principal, que representa a execuo mais normal da funo; e os subfluxos e fluxos alternativos, que representam variantes que so executadas sob certas condies. A UML permite que diversas notaes sejam utilizadas para descrever os detalhes dos casos de uso.
Toda mercadoria a ser vendida (item de venda) deve estar previamente cadastrada. O Merci deve estar no Modo de Vendas.
Tabela 1 - Precondies de um caso de uso

Os fluxos so comumente descritos em linguagem natural, na forma de uma seqncia de passos (Tabela 2). Cada passo corresponde a uma ao de um ator ou do produto; estes devem aparecer explicitamente como sujeitos da frase. Outros atores podem aparecer como objetos verbais de uma ao. Condies e iteraes podem aparecer, mas os detalhes destas devem ser descritos em subfluxos, de preferncia. Isso ajuda a manter a legibilidade do fluxo, que essencial para garantir o bom entendimento de todas as partes.
6

O Caixeiro faz a abertura da venda. O Merci gera o cdigo da operao de venda. Para cada item de venda, o Merci aciona o subfluxo Registro. O Caixeiro registra a forma de pagamento. O Caixeiro encerra a venda. Para cada item de venda, o Merci aciona o subfluxo Impresso de Linha do Ticket. O Merci notifica o Sistema Financeiro informando: Data, Nmero da Operao de Venda, Receita, Valor Total, Nome do Cliente (caso tenha sido emitida a nota fiscal).
Tabela 2 - Fluxo principal

Quando uma condio ou iterao for composta por uma seqncia muito curta de passos, elas podem ser representadas por meio de endentao.
O Gestor de Compras seleciona a mercadoria. O Merci verifica se existe algum pedido pendente que contenha esta mercadoria. Se no houver pedido pendente contendo a mercadoria a ser excluda: o Merci desvincula a mercadoria dos fornecedores (os fornecedores no mais fornecero a mercadoria que esta sendo excluda). o Merci faz a remoo da mercadoria. Se houver pedido pendente contendo a mercadoria a ser excluda o Merci emite uma mensagem de erro.
Tabela 3 Fluxo principal com condicionais endentados

Os subfluxos descrevem geralmente detalhes de iteraes, ou de condies executadas com freqncia (Tabela 4).
O Caixeiro registra o item de venda, informando a identificao e a quantidade. O Merci totaliza a venda para o cliente da mercearia.
Tabela 4 - Exemplo de subfluxo: Registro de item em Operao de Venda

Os fluxos alternativos descrevem condies pouco habituais ou excees (Tabela 5).

Se o Gestor de Compras solicitar: o Merci imprime o pedido de compra.
Tabela 5 - Exemplo de fluxo alternativo: Impresso de Pedido de Compras

2.5

Diagramas de estados

Para casos de uso complexos, pode-se descrever seu comportamento de maneira mais formal, atravs de um diagrama de estados ou diagrama de atividade da UML. Diagramas de estados so utilizados para descrever fluxos de lgica complexa ou com muitos detalhes, como costuma acontecer nos casos de uso de desenho (Figura 10). As principais convenes so mostradas na Tabela 6.

Smbolo Retngulo com cantos arredondados Seta cheia Pequeno crculo cheio Crculo cheio dentro de crculo vazio Estado.

Descrio

Transio entre estados diferentes ou de um estado para si mesmo (transies reflexivas). Estado inicial. Estado final.

Tabela 6 - Smbolos dos diagramas de estados

Os eventos que provocam as transies aparecem como rtulos destas. Se a transio depender de uma condio, esta pode ser representada por uma guarda (texto entre colchetes). Anotaes so utilizadas para complementar o modelo; por exemplo, indica-se, na Figura 10, que se pode invocar a tela de nota fiscal no estado Atualizada.

F ec ha r [ c o nf irm a o ]

E m itir N F A tua li za da

Tela d e N ota F is c a l

F ec har [ c o nf irm a o ]

In c luir I tem E x c lu ir Ite m [ s e algu m it em C on f irm ar V en da tiv e r s id o s e le c io n ad o ]

V azia C an ce la r Vend a

A lte ra da

In c luir I tem

O K, C a nc ela r[ s e e x is t ir a lgu m it em inc lu d o ] In c lui r It em

C an c e la r [ s e n o e x is tir n en hu m it em inc lu d o ] In c lu ind o Ite m

Figura 10 Diagrama de estado de caso de uso

Diagramas de estado podem ser usados para mostrar lgica bastante complexa. Na Figura 11, os estados complexos X e Y tem subestados, que so usados para exprimir a seguinte lgica: O estado inicial conduz a X, dentro qual existe um subestado inicial que conduz a X1. Ao entrar em X1, a ao A0 executada. O evento E1 leva ao subestado X2. No subestado X2, se o evento E2 ocorrer com a condio C1, executada a ao A1 e continua-se no subestado X2. Se E2 ocorrer com a condio C1 falsa, executa-se a ao A2 e passa-se para o subestado Y1 do estado Y.
8

Durante a permanncia no subestado Y1 executada a ao A4. Se no subestado Y1 ocorrer o evento E3, executa-se a ao A3 e passa-se ao subestado Y2. Se no subestado Y2 ocorrer o evento E4, volta-se ao estado X; na sada de Y2 envia-se o evento E5, que pode provocar alguma transio no mostrada nesse diagrama. Se no estado Y (em qualquer subestado) ocorrer o evento E6, vai-se para um estado final.

E 2[ C1 ] / A1

X X1 entry : A 0 E1 X2

E 2[ ~ C1 ] / A 2

E4 Y

Y1 E6 do: A 4

E3 / A 3

Y2 ex i t: ^E5

Figura 11 Diagrama de estados complexo

2.6

Diagramas de atividade

Estes diagramas so uma variante dos fluxogramas, sendo geralmente usados para descrever processos de negcio, ou outros fluxos onde o paralelismo de atividades seja importante. A Figura 12 apresenta um exemplo de diagrama de atividades. A Tabela 7 explica os smbolos usados.

Smbolo Retngulo ovalado Retngulo Seta cheia Seta pontilhada

Descrio Atividade (passo do fluxo). Objeto (artefato do fluxo). Relao de precedncia entre atividades. Consumo ou produo de objeto por atividade.

Linha horizontal cheia Ponto de sincronizao (onde subfluxos paralelos se juntam). Pequeno crculo cheio Crculo cheio dentro de crculo vazio Estado inicial. Estado final.

Tabela 7 - Smbolos dos diagramas de atividades

Nesse exemplo, mostra-se que as atividades Detalhamento dos requisitos de interface e Detalhamento dos casos de uso so realizadas em paralelo, mas a atividade Detalhamento dos requisitos no funcionais requer que ambas estejam completas. Os objetos mostrados direita representam os resultados das atividades.

10

Definio do contexto

PESw

Definio do escopo

ERSw Introduo

Definio dos requisitos

ERSw Descrio geral

Detalhamento dos requisitos de interface

Detalhamento dos casos de uso

MASw Viso de casos de uso

ERSw Requisitos especficos Detalhamento dos requisitos no funcionais

Classificao dos requisitos

CRSw Itens de requisitos

Reviso dos requisitos

Figura 12 Exemplo de diagrama de atividades

Um diagrama de atividades mais complexo mostrado na Figura 13. Ele dividido em raias (swimlanes), que representam os diversos papis de pessoas ou grupos envolvidos no processo (no exemplo, cliente da mercearia, caixeiro e gerente). Os objetos situados sobre as fronteiras das raias representam objetos partilhados entre os papis. Em um processo de negcio, eles podem representar tanto objetos fsicos quanto informacionais. Um losango de deciso tem como sadas subfluxos alternativos (no exemplo, a emisso opcional de nota fiscal).

11

Cliente da mercearia

Caixeiro

Gerente

Escolha dos itens de mercadoria

Abertura do caixa

Itens de mercadoria

Registro das compras

Totalizao da venda

Emisso do tquete

Caixa

Tquete

Desembolso do pagamento

Pagamento

Recebimento do pagamento

Empacotamento dos itens Pediu nota fiscal No pediu nota fiscal Emisso da nota fiscal Registro no caixa

Fechamento do caixa

Nota fiscal

Figura 13 Exemplo de modelo de processo de negcio

3
3.1

Modelagem lgica
Objetos e classes

Nas metodologias de modelagem orientadas a objetos, os objetos representam entidades discretas, com fronteira bem definida e identidade prpria, que encapsulam estado e comportamento. O estado representado pelos atributos do objeto, e o comportamento pelas respectivas operaes. Os objetos interagem entre si trocando mensagens, que so invocaes das operaes. Objetos similares so agrupados em classes. Na UML, um objeto representado por um retngulo, onde o nome do objeto sublinhado. Quando um objeto aparece em um diagrama UML, podem acontecer as seguintes situaes:
12

 Um objeto pode ter classe indeterminada (Figura 14). Esta uma situao transitria que pode acontecer durante a anlise, mas deve ser resolvida. Um objeto pode ter denominao prpria e pertencer a uma determinada classe (Figura 15). O nome da classe separado do nome do objeto por um sinal de dois pontos. Um objeto pode ser annimo, representando uma instncia genrica de determinada classe (Figura 16). O campo esquerda dos dois pontos fica vazio.
V enda c orrente

Figura 14 - Objeto sem classe determinada

V enda c orrente : V enda

Figura 15 - Objeto com indicao da respectiva classe

: M erc adoria

Figura 16 - Objeto annimo

< < Control> > V enda + + + + + + + + + + + + + + + F orm a de P agam ento V alor Data Itens : Itens de V enda Im pos tos Ins erir Item V enda() Totalizar() E m itir Tick et() E m itir Nota F is c al() Im prim ir Nota F is c al() F inalizar Im press o Nota F isc al() Totalizar Im pos tos () F inaliz ar Im pres s o Tic k et() E x c luir Item V enda() Nova V enda() G erar Cdigo() Tipo de P agam ento() F inaliz ar V enda() V enda A berta() V enda Conc luda()

Figura 17 - Representao de classe

13

Na UML, a classe representada por um retngulo dividido em trs compartimentos, que contm respectivamente o nome da classe, os atributos e as operaes. Para maior clareza nos diagramas, pode-se suprimir cada um dos compartimentos de atributos e operaes, ou deixar de mostrar determinados atributos ou operaes. So opcionais tambm: a indicao da visibilidade por caracteres ou cones; a assinatura (lista de argumentos e tipo de retorno) das operaes; e o tipo e valor padro dos atributos.
Ven d a - Fo rm a d e P a g am en to - Va lo r - D ata

Figura 18 - Representao de classe com supresso das operaes

< < Control>> V en da + + + + + + + + + + + + + + + F orma de P ag am ento V al or Data Itens : Itens de V enda Impos tos Ins eri r It em V enda(produ to : Merc adoria = d efau lt , quant idade = defa ult) Totaliz ar(total do item : Item de V enda = default) E m i ti r Tic k et() E m i ti r Nota Fis c al() Im prim ir Nota F is c al() F inali z ar Im pr ess o No ta F is c a l() T otali z ar Im pos tos () : ret urn F inali zar Im pr es s o Tic k et() E x c lui r Item V enda() Nova V enda() G erar Cdigo() T ipo de Pa gam e nto() F inaliz ar V enda() V enda A berta() : return V en da Conc luda() : ret urn

Figura 19 - Representao de classe com detalhamento das assinaturas das operaes

3.2 3.2.1

Organizao das classes Pacotes lgicos

Os pacotes lgicos so agrupamentos de elementos de um modelo. No modelo de anlise, eles podem ser utilizados para formar grupos de classes com um tema comum. Na Figura 20, os pacotes lgicos Compras, Vendas e Administrao so usados para agrupar classes especializadas em relao a esses aspectos.

14

V en d a s

Co m p ra s

A d mi n i stra o

Figura 20 - Pacotes lgicos

Pacotes lgicos podem ter relaes de dependncia e continncia entre si. Na Figura 21, os pacotes lgicos Classes de fronteira e Classes de controle dependem (importam recursos) de Colees de entidades. Colees de entidades contm os pacotes Colees e Elementos. Classes VB um pacote global: seus recursos esto disponveis para os elementos de todos os outros pacotes.

Cl ass es de fronteira

Clas s es de c ontrole

Clas s es V B

g lo ba l

Clas s es de entidade

Cole es (from Clas ses de entidade)

E lem entos ( from Cl as s es de en ti dade)

Figura 21 Relacionamentos entre pacotes lgicos

3.2.2

Esteretipos

Os esteretipos so extenses de elementos do modelo. Podem ser usados para denotar especializaes significativas de classes. Os atores, por exemplo, podem ser tratados pelas ferramentas de modelagem como classes estereotipadas. Como mostra a Figura 22, esteretipos podem ser indicados atravs de cones prprios, ou incluindo-se o nome do esteretipo em aspas francesas (os caracteres , representados nos desenhos por << >>).
< < Acto r>> C a ixe iro C a ixe iro

Figura 22 - Representaes alternativas do esteretipo "Ator"

15

Esteretipos so usados para criar especializaes da UML em relao a determinadas reas de modelagem. Jacobson ([Jacobson94], [Jacobson+99]) prope a diviso das classes do Modelo de Anlise de acordo com os esteretipos descritos a seguir, que foram incorporados ao padro oficial da UML. Na Figura 23 eles so representados de forma textual, e na Figura 24 so representados na forma icnica. Entidades ("entity") modelam informao persistente, sendo tipicamente independentes da aplicao. Geralmente so necessrias para cumprir alguma responsabilidade do produto, e freqentemente correspondem a tabelas de bancos de dados. Fronteiras ("boundary") tratam da comunicao com o ambiente do produto. Modelam as interfaces do produto com usurios e outros sistemas, e surgem tipicamente de cada par ator caso de uso. Controles ("control") coordenam o fluxo de um caso de uso complexo, encapsulando lgica que no se enquadra naturalmente nas responsabilidades das entidades. So tipicamente dependentes de aplicao.
< < E n ti ty> > I te m d e V en d a < < Co n tro l > V e nd a < < B o u n d a ry> > T ela de Vend as

Figura 23 - Exemplo de classes de anlise com esteretipos textuais

Item de V enda
(fro m C l a sse s d e E n ti d a d e )

V enda
(fro m C l a sse s d e C o n tro l e )

Tela de V endas
(fro m C l a sse s d e Fro n te i ra )

Figura 24 - Exemplo de classes de anlise com esteretipos icnicos

3.3 3.3.1

Relacionamentos Relacionamentos de associao

As associaes expressam relaes bidirecionais de dependncia semntica entre duas classes. Elas indicam a possibilidade de comunicao direta entre os respectivos objetos. Isso significa que faz parte das responsabilidades de um objeto de uma das classes determinar os objetos correspondentes da outra classe. Normalmente, existiro em cada classe operaes para cumprir essa responsabilidade.
E m p re s a in clu ir p ro d u to () e xclu ir p ro d u to () Me rca d o ria in clu i r fo rne c e d or() e xclu ir forn e ce d or() li s ta r fo r ne ce d o re s ()

Figura 25 - Relacionamento de associao

3.3.2

Multiplicidades e papis

A especificao das associaes inclui o seu nome, descrio e possveis restries. Em certos casos, til batizar tambm os papis, assim como especificar vrios detalhes destes. Os nomes das
16

associaes devem ser simples e significativos. Recomenda-se usar um substantivo que descreva bem a semntica do relacionamento. Pode-se tambm usar um verbo, desde que esteja claro qual classe sujeito e qual classe objeto desse verbo (Figura 26). Uma conveno habitual batizar o relacionamento de modo que ele seja lido corretamente de cima para baixo ou da esquerda para a direita. Na ltima verso da UML, um pequeno tringulo pode ser usado para indicar a direo de leitura, caso necessrio.

F ornec e

E m pres a

M erc adoria

E mprega

P es s oa

Figura 26 - Relacionamento com nome

A multiplicidade de um participante de um relacionamento indica quantos objetos de uma classe se relacionam com cada objeto da outra classe. Relacionamentos obrigatrios tm multiplicidade mnima 1. A multiplicidade mxima indica o nmero mximo de instncias da classe alvo que podem existir simultaneamente. Na Figura 27 modela-se o fato de que uma Pessoa pode estar ligada a nenhuma ou uma Empresa, enquanto uma Empresa pode estar relacionada com uma ou mais instncia de Pessoa (por exemplo, empregar). Uma Empresa pode estar relacionada com zero ou mais instncias de Mercadoria (por exemplo, fornecer).

E m pres a 0..* 0..1 0..*

M erc adoria

1..* P es s oa

Figura 27 - Relacionamentos com multiplicidades

Os papis so denominaes que exprimem em que qualidade um objeto de uma das classes do relacionamento se relaciona com um objeto da outra classe.Os papis dos participantes devem ser batizados explicitamente quando participarem de um relacionamento em uma qualidade que no implcita no respectivo nome da classe. Na Figura 28 indica-se que um objeto da classe "Empresa" participa no papel de "fornecedor" do relacionamento "Fornece", com zero ou mais objetos da classe
17

"Mercadoria", e um objeto dessa classe se relaciona com zero ou mais objetos da classe "Empresa" na qualidade de "produto". Uma "Empresa" pode participar de outros relacionamentos em outras qualidades; por exemplo, no papel de "empregador", em um relacionamento "Emprega" com um objeto da classe "Pessoa".

Empresa

fornecedor 0..*

Fornece

produto 0..*

Mercadoria

empregador

Emprega

empregado Pessoa

Figura 28 - Relacionamentos com denominao dos participantes

3.3.3

Navegabilidade

Os relacionamentos podem ter direo de navegao. Um relacionamento navegvel da classe A para a classe B se, dado um objeto da classe A, consegue-se obter de forma direta (por exemplo, atravs de uma operao da classe A) os objetos relacionados da classe B. Por exemplo, a Figura 29 indica que, dada uma "Mercadoria", possvel localizar diretamente o respectivo "Fornecedor", mas a recproca no verdadeira.

Empresa

0..* fornecedor

Fornece

0..* produto

Mercadoria

Figura 29 - Relacionamento com restrio de navegabilidade

3.3.4

Relacionamentos de herana

O relacionamento de herana existe entre classes de natureza mais geral (chamadas de superclasses ou classes bases) e suas especializaes (chamadas de subclasses ou classes derivadas). As superclasses contm atributos ou operaes comuns a um grupo de subclasses. Na Figura 30 modela-se o fato de que um Item de Compra um tipo (uma especializao) de Item de Mercadoria, assim com um Item de Venda.

18

< < E ntity > > Item de Mercadoria

(fro m A d mi n i stra o )

- Q uantidade - P re o Total - m erc adoria : M erc adoria + + + + Totalizar() Ins erir() Tipo de O pera o() E x c luir()

< < E ntity > > Item de Com pra

(fro m Co m p ra s)

<< E ntit y> > It em de Ven da

( fr om V e n da s)

+ D ar B aix a()

+ Im prim ir Item Tic k et() + Calc ular Im pos tos () + Im prim ir Item Nota F is c al()

Figura 30 - Exemplo de relacionamentos de herana

3.3.5

Relacionamentos avanados

Um relacionamento de agregao uma associao que reflete a construo fsica ou a posse lgica. Relacionamentos de agregao so casos particulares dos relacionamentos de associao, e s necessrio distingui-los quando for conveniente enfatizar o carter "todo-parte" do relacionamento. Geralmente um relacionamento de agregao caracterizado pela presena da expresso "parte de" na descrio do relacionamento, e pela assimetria da navegao.
Contorno
P olgono 1..1 + vrtic e 3. .* P onto

Figura 31 - Relacionamento de agregao

Um tipo mais forte de relacionamento todo-parte o relacionamento de composio. Nesse caso, os objetos da classe parte no tm existncia independente da classe todo. A Figura 32 indica que o "centro" de um "Crculo" no tem existncia independente deste, enquanto que a Figura 31 indica que cada "ponto" existe independentemente do "Polgono" ao qual serve de "vrtice".
Crculo centro Figura 32 - Relacionamento de composio Ponto

19

Uma associao pode ser reflexiva. Uma auto-associao indica um relacionamento entre objetos de mesma classe que desempenham diferentes participaes. Na Figura 33 indica-se uma Pessoa na qualidade de chefe relaciona-se com uma ou mais instncias de Pessoa que exercem o papel de subordinado.
Pessoa chefe subordinado 1..* 1..1

Figura 33 - Associao reflexiva

Os relacionamentos podem ser de natureza complexa. Em certos casos, um relacionamento mais bem explicado atravs de uma classe de associao, que exprime atributos e at operaes que so propriedades do relacionamento como um todo e no de cada participante isoladamente. Na Figura 34 a classe Emprego inclui atributos e operaes que no esto ligados a uma Empresa ou uma Pessoa isolada, mas ao relacionamento entre elas; por exemplo, o atributo data de incio ou a operao imprimir atestado de emprego.
Emprega
Empresa empregador 0..1 empregado 1..* Pessoa

Emprego

Figura 34 - Classe de associao

Um qualificador um atributo que restringe um relacionamento atravs de uma seleo. Na maioria dos casos, cada valor do qualificador est associado a uma nica instncia da classe alvo. Na Figura 35, o qualificador "nmero de conta" restringe a participao de objetos da classe "Pessoa" no relacionamento. Um "nmero de conta" pode estar associado a zero ou um cliente (contas conjuntas no so modeladas).
Banco nmero de conta 0..* Figura 35 - Relacionamento com qualificador cliente 0..1 Pessoa

3.4 3.4.1

Detalhes das classes Mensagens e operaes

Em modelos orientados a objetos, as mensagens representam os mecanismos de interao entre estes. Um objeto s pode receber mensagens que correspondam invocao de uma operao da respectiva
20

classe. Durante a execuo da modelagem, os diagramas podem conter, em carter provisrio, mensagens no associadas a operaes de alguma classe. Entretanto, ao trmino da anlise todas as mensagens tm de ser resolvidas em termos de operaes de alguma classe. Uma mensagem tem as seguintes partes: receptor - o objeto que recebe a mensagem; operao - a funo requisitada do receptor; parmetros - os dados para a operao. Na Figura 36 modela-se uma interao simples entre dois objetos, atravs de uma mensagem sem parmetros.
1: Im prim ir Tic k et( ) : V enda : Item de V enda

Figura 36 - Exemplo de mensagem sem parmetro

Na Figura 37 modela-se uma colaborao complexa que envolve um ator (a rigor, uma instncia de ator) e vrios objetos. Os parmetros das mensagens so includos no modelo.
: Controle_de_G es tao _de_F ornec edores

1: c m dIncM erc O K _Clic k( ) 2: Inc luir_M erc adoria(Long) : G es t or de Com pras

: frm F ornec edores 5: E x iste_F ornec im ento(Long, Long) 6 : Ad d(F ornec im e nto, S t ring, V ar iant, V ariant) 3: E x is te_M erc adoria( Long) 4: It em (V ariant)

: M erc adorias

: F ornec im entos

Figura 37 Exemplo de mensagens com parmetros

3.4.2

Atributos

Atributos so propriedades que descrevem as classes. Atributos equivalem a relacionamentos de composio em que: a classe parte o tipo do atributo; o papel o nome do atributo. Atributos e relacionamentos podem ser alternativas para se expressar os mesmos conceitos (Figura 38). A escolha entre atributo e relacionamento deve visar clareza do modelo. Geralmente atributos so de tipos equivalentes a classes pequenas e reutilizveis, que representam abstraes de nvel superior ao do domnio do problema.

21

Tringulo Tringulo vrtice[3] : Ponto 3 vrtice Ponto

Figura 38 Equivalncia entre atributos e composies

3.4.3

Controle de acesso

Os tipos de acesso a operaes ou atributos de cada classe incluem: pblico: qualquer outra classe pode usar (smbolo na UML +); protegido: s subclasses dessa classe podem usar (smbolo na UML #); privado: nenhuma outra classe pode usar diretamente (smbolo na UML -); implementao: declarado no corpo de uma operao. Excees ao controle normal de acesso, para determinadas classes clientes, podem ser feitas declarando-se essas classes como amigas da classe fornecedora. Na Figura 39 so mostrados os controles de acesso dos atributos e operaes de uma classe implementada em Visual Basic. Note-se que todos os atributos so privados. So pblicas as operaes provenientes do modelo de anlise e as operaes de acesso aos atributos; so privadas as operaes de incio e trmino da vida dos objetos.

22

< < Clas s M odule> > F ornec edor m Nom e : V ariant m Tele fone : V aria nt m C PF _CG C : V ari ant m E nderec o : V ari ant m lC las s DebugID : Long

+ Co ns is t ir() + Ve rific ar_V inc ulo _M erc adoria() + Ins eri r_V inc u lo_M erc ador ia() + Ve rificar_P edido_Compr a() + Ex c lui r_V inc ulo_ M erc adoria() + E m i tir_Rel ator io() < < G et> > + Clas sDebugID() - Cl as s _Init ial iz e() - Clas s _Term inate() < < S et> > + N om e() < < G et> > + N om e() < < S et> > + Tel efon e() < < G et> > + Tel efone() < < S et> > + CP F _CG C() < < G et> > + CP F_CG C() < < S et> > + E ndere c o() < < G et> > + E nderec o() + Prox i ma_M erc ador ia ()

Figura 39 - Exemplo de controles de acesso

Note-se tambm, na Figura 39, o uso de esteretipos para indicar que construes da linguagem alvo sero utilizadas para implementar a classe (<< Class Module >>) e as operaes de acesso aos atributos (<< Get >>, << Set >>).

3.5 3.5.1

Diagramas de interao Diagramas de seqncia

Os diagramas de seqncia enfatizam o ordenamento temporal das aes. Eles so construdos de acordo com as seguintes convenes: linhas verticais representam os objetos; setas horizontais representam as mensagens passadas entre os objetos; rtulos das setas so os nomes das operaes; a posio na vertical mostra o ordenamento relativo das mensagens; o diagrama pode ser complementado e esclarecido por anotaes. A UML prev que os retngulos situados nas linhas verticais devem indicar o tempo de vida dos objetos. Esta conveno no foi seguida neste texto, por limitao da ferramenta de modelagem utilizada.
23

O Gestor de Compras seleciona a mercadoria. O Merci verifica se existe algum pedido pendente que contenha esta mercadoria. Se no houver pedido pendente contendo a mercadoria a ser excluda, o Merci desvincula a mercadoria dos fornecedores (os fornecedores no mais fornecero a mercadoria que esta sendo excluda); o Merci faz a remoo da mercadoria. Se houver pedido pendente contendo a mercadoria a ser excluda, o Merci emite uma mensagem de erro.
Tabela 8 - Exemplo de fluxo de caso de uso

Os diagramas de seqncia so orientados para exprimir, de preferncia, o desenrolar temporal de seqncias de aes. mais difcil representar lgicas de seleo e repetio sem prejudicar a inteligibilidade do diagrama. Os roteiros representam desdobramentos da lgica do caso de uso. prefervel usar diagramas separados para representar roteiros resultantes de diferentes caminhos lgicos. Por exemplo, a lgica contida no fluxo da Figura 40 pode ser descrita atravs dos diferentes roteiros (Figura 41 e Figura 42). Para simplificar o exemplo, os diagramas no usam classes de fronteira.
O Caixeiro registra itens de mercadoria. O Merci totaliza venda. O Caixeiro registra modo de venda. Se venda a prazo, o Caixeiro insere venda em contas a receber. Seno, o Caixeiro registra pagamento.
Figura 40 Exemplo de fluxo com lgica de seleo: Operao de Venda

24

: V enda

: Caix a

: Caix eiro

1: tot al iz ar( )

2: regis trar m odo( )

3: regi strar pagam ent o( )

Figura 41 Exemplo de roteiro alternativo: Operao de Venda Vista

: V enda

: Contas a rec e ber

: Caix eiro 1: totaliz ar( )

2: regi strar m odo( )

3: ins erir(V enda)

Figura 42 Exemplo de roteiro alternativo: Operao de Venda a Prazo

25

Subfluxos curtos podem ser inseridos em um roteiro, indicando-se a lgica de ativao deles por meio de expresses de recorrncia: [condio] - lgica de seleo; *[condio] - lgica de iterao.

: Caix eiro

: Venda

: Contas a receber

: Ca ix a

1: totalizar( )

2: regi s tr ar m odo( )

[venda a prazo] 3: ins erir(V en da)

[venda vis ta] 4: regi s tr ar pagam ent o( )

Figura 43 Representao de lgica por meio de restries

Diagramas de seqncia podem ser complementados por meio de anotaes. Os detalhes de processamento que no correspondem a interaes entre classes foram lanados como anotaes no diagrama da Figura 44. Estas anotaes podem servir como especificaes das operaes das classes envolvidas.

26

: G es tor de C om pr as

: fr m F orn ecedore s

: C ont role_ de_Ge s ta o_de _ F or n ec e dor e s

: M erc ador ia s

: F or necim entos

fr m For nec edor es exibe e habilita o c am po C digo da N ova M er cador ia e o boto OK.

O Gestor de C om pr as pr eenc he o c am po C digo da N ov a M er cador ia

1: c m dInc M er cO K_C lick ( )

fr m For nec edor es esc onde e desabilita o c am po C d ig o d a N ova M er c ador ia e o bo t o OK.

2: Inc luir _M er cador ia( Long)

3: Exis te_M er cador ia( Long)

Se o C digo pr eenchido no exis tir na tabela M er c ador ias do banc o de dados M er ci, C ontr ole_de _Ges tao_de_F or nec edor es executa a exc e o EGF - 03.

4: Item ( Var iant)

5: Exis te_For nec im ento( Long, Long)

Se o p ar fo rm ado p elo C d ig o da me r ca dor ia e pel o C digo do F or nec edor j exis tir , C ontr ole_de_ Ges ta o_de _For nece dor es ex e cut a a exce o EGF - 04. 6: Add( F or necim ento, Str ing, Var iant, Var iant)

fr m For nec edor es exibe m ais um a linha na gr ade d o quadr o de M er cador ias F or nec idas, contendo os c am pos C digo e D esc r io da m er c ador ia inc luda.

Figura 44 Exemplo de diagrama de seqncia para realizao de um caso de uso

3.5.2

Diagramas de colaborao

Os diagramas de colaborao enfatizam os relacionamentos entre os objetos participantes. Eles so construdos de acordo com as seguintes convenes: nodos representam os objetos;

27

 os arcos representam as mensagens passadas entre os objetos; os rtulos dos arcos so os nomes das operaes; os nmeros de seqncia mostram o ordenamento relativo das mensagens; as anotaes podem complementar o diagrama. Nos diagramas de colaborao a ordenao das mensagens mostrada apenas pela numerao delas. Na Figura 46 mostra-se o diagrama de colaborao que corresponde ao diagrama de seqncia da Figura 45.

: Ges t or de C om pras

: Tela d e Merc adorias

: C on trolad or de M erc ad orias : Merc a doria

: F ornec edor

: P edido de C om pra

1 : E x c luir( )

2: E x clu ir( Merc a doria)

3: V erif ic ar Merc adorias Pende ntes (Merc adoria)

[S e no houv er P edidos P endent es ] 4: E x c lu ir( )

* [ P ara c ada f ornec edor] 5: E x c lu ir V nc ulo(Merc adoria)

Figura 45 - Realizao de fluxo atravs de diagrama de seqncia

28

1: E x c luir( ) : Tela de M erc adorias : G es tor de Com pras

2: E x c lu ir(M erc a dori a) : Co ntrolad or de M erc adorias

3: V erific ar M erc adorias P endentes (M erc adoria) : P edido de Co m pra

4: E xc l uir( )

5: E x c luir V nc ulo(M erc adoria) : Mer c adoria : F ornec edor

Figura 46 - Realizao de fluxo atravs de diagrama de colaborao

3.5.3

Diagramas de objetos

Diagramas de colaborao mostram interaes entre objetos, que geralmente tm o objetivo de cooperar para realizar roteiro de um caso de uso. Diagramas de objetos podem ser utilizados tambm para outras finalidades. Na Figura 47, um diagrama de objetos ilustra a integrao bottom-up. No exemplo, as unidades U21 e U22 so testadas utilizando-se os controladores C1 e C2. No passo seguinte da integrao, os controladores so substitudos pela unidade U1. Substitudo por uma ligao entre dois objetos.
Su bs ti tudo por

C1 : Controlador

C2 : Controlador

S ubs titudo por

U1 : Unidade

U21 : Unida de

U22 : Unidade

U21 : Unidade

U22 : Unidade

A NTE S

DE P O IS

Figura 47 Exemplo diagrama de objetos utilizado para ilustrar testes

29

Os diagramas de objetos podem ser usados para mostrar a passagem de dados e de controle. Na Figura 48, por exemplo, mostram-se como objetos uma unidade sob teste e os componentes utilizados para testa-la. As setas simples representam a direo de fluxo de controle: do objeto que chama (cliente do servio ou emissor da mensagem) para o objeto chamado (fornecedor do servio ou receptor da mensagem). As setas com bolinhas indicam o fluxo de dados (direo de passagem de parmetros).

: Cas o de tes te 3: 1: 2: A : Coto

: Controlador

: Unidade

4:

5: : E x ibidor B : Coto

Figura 48 - Componentes de teste

4
4.1

Modelagem fsica
Viso de componentes

A viso de componentes descreve os aspectos estticos do modelo fsico. Ela mostra os arquivos de cdigo fonte e objeto utilizados na implementao, assim como componentes reutilizados do ambiente e de outros projetos. Mostra tambm as dependncias existentes entre eles, que indicam o impacto das alteraes realizadas em cada componente. Na Figura 49, mostra-se que o componente executvel Merci_10 depende de vrios componentes de cdigo fonte correspondentes a formulrios do Visual Basic e de um componente de cdigo binrio da tecnologia COM (um controle ActiveX de grade de entrada).

30

frm F ornec edores .frm

m di P ri nc ipal.frm

frm M erc adorias .frm

frm P edidos _de _Com pras .frm

frm Com pras .frm

M erc i_ 10

< < A c tiveX> > M S F lex G rid Lib

Figura 49 Exemplo de diagrama de componentes (viso esttica)

Os componentes podem ser implementados por meio de muitos tipos diferentes de arquivos. Nos diagramas de componentes, esses tipos de arquivos podem ser destacados por meio de esteretipos, representados por meio de identificadores ou de cones prprios. A Figura 50 mostra alguns tipos de arquivos fontes, com os respectivos esteretipos icnicos. A Figura 51 mostra alguns exemplos de componentes de cdigo objeto comuns em ambientes Windows, mostrados com esteretipos textuais.
E s pec ific a o de s ubprogram a

C orp o de s ubprogram a

C om ponente genric o

Prog ra ma p ri nci pal

E s pec ific a o de pac ote

C orp o de pac ote

E s pec ific a o de ta re fa

Co rpo de tare fa

Figura 50 Exemplo de componentes de cdigo fonte

31

A rquivo_E XE

A rqui vo _DL L

< < A c tiveX> > Com ponente _A c tiveX

< < A pplet> > M ini -a pli c ativo

Figura 51 Exemplo de componentes de cdigo objeto

As interfaces representam um subconjunto dos recursos implementados por um componente, que tm um tema comum. Por exemplo, na Figura 52, um componente ActiveX oferece duas interfaces distintas. Aplicativos que no tratem de vendas a prazo, por exemplo, possivelmente no utilizaro a interface Gestao_de_Clientes, utilizando apenas os recursos oferecidos atravs da interface Operacao_de_Venda.

G es tao_de_Clientes

< < A c tiveX> > G es tao_de_ V endas

O perac ao_de_V enda

Figura 52 Exemplo de interfaces de componente

4.2

Viso de desdobramento

O modelo fsico dinmico descrito pelo diagrama de desdobramento, que mostra os processadores, os dispositivos e as conexes utilizados na implementao de um sistema. Em cada processador, pode-se mostrar os processos que nele executaro. Esse modelo particularmente importante no caso de sistemas distribudos. comum a utilizao de esteretipos para indicar diferentes tipos de processadores e dispositivos. Na Figura 53 mostra-se que os processadores Cliente de WWW 1, Cliente de WWW 2 e Servidor de bancos de dados so ligados ao processador Servidor de WWW atravs de conexes Internet. O Servidor de WWW executa os processos Personal Web Server e Aplicativo CGI. O Cliente de WWW 1 est ligado a um dispositivo Impressora.

32

Im pres s ora

S ervi dor de WWW

P e rso n a l We b S e rve r A p l ica ti vo CG I

< < Internet> > << Internet > >

< < Intranet> >

Cliente de W W W 1

Cliente de W W W 2

S ervidor de banc os de dados

Figura 53 - Exemplo de diagrama de desdobramento

Referncias
[Jacobson+99] [Jacobson94] [Rumbaugh+99] Ivar Jacobson, James Rumbaugh e Grady Booch. Unified Software Development Process. Addison-Wesley, Reading - MA, 1999. Ivar Jacobson. Object-Oriented Software Engineering. Addison-Wesley, Reading - MA, 1994. James Rumbaugh, Ivar Jacobson e Grady Booch. Unified Modeling Language Reference Manual. Addison-Wesley, Reading - MA, 1999.

33