Captulo 4 - UML VISO GERAL

Tpicos
Introduo
Viso Histrica
Tipos de Elementos Bsicos
Tipos de Relaes
Tipos de Diagramas
Mecanismos Comuns
Organizao dos Artefactos Pacotes

4.1 Introduo
O Unified Modeling Language (UML) uma linguagem para especificao, construo,
visualizao e documentao de artefactos de um sistema de software.
promovido pelo Object Management Group (OMG) com contribuies e direitos de
autoria das seguintes empresas: Hewlett-Packard, IBM, ICON Computing, i-Logix,
IntelliCorp, Electronic Data Services, Microsoft, ObjecTime, Oracle Platinum, Ptech,
Rational Reich, Softeam, Sterling, Taskon A/S e Unisys.
O UML providencia as seguintes particularidades principais [OMG99]:
Semntica e notao para tratar um grande nmero de tpicos actuais de modelao.
Semntica para tratar tpicos de modelao futura, relacionados em particular com a
tecnologia de componentes, computao distribuda, frameworks e Internet.
Mecanismos de extensibilidade de modo que futuras aproximaes e notaes de
modelao possam continuar a ser desenvolvidas sobre o UML.
Semntica e sintaxe para facilitar a troca de modelos entre distintas ferramentas.
O UML alarga o mbito de aplicaes alvo comparativamente com outros mtodos
existentes, designadamente porque permite, por exemplo, a modelao de sistemas
concorrentes, distribudos, para a Web, sistemas de informao geogrficos, etc.
A nfase do UML na definio de uma linguagem de modelao standard, e por
conseguinte independente das linguagens de programao, das ferramentas CASE,
bem como dos processos de desenvolvimento. A razo referida que dependendo do
tipo de projecto, da ferramenta de suporte, ou da organizao envolvida, devem ser
adoptados distintos processos/metodologias, mantendo-se contudo a utilizao da
mesma linguagem de modelao.

CENTRO ATLNTICO - COLECO T ECNOLOGIAS

O UML independente das ferramentas de modelao. Apesar da especificao do

UML incluir sugestes para os fabricantes de ferramentas adoptarem na apresentao
dessas notaes (e.g., tpicos como o desenho de diagramas, cor, navegao entre
esquemas, etc.), no aborda todos os requisitos necessrios por no ser esse,
propositadamente, o seu objectivo.
Um princpio bsico no esforo de definio do UML foi a simplicidade. Outro princpio
foi a coerncia na unificao de diferentes elementos existentes em vrios mtodos,
entre outros Booch [Boo94], OMT [RBP+91] e OOSE [Jac92], e introduo de novos
elementos apenas quando tal fosse absolutamente necessrio, i.e., quando tais
elementos no existissem em mtodos anteriores.
Os novos elementos introduzidos no UML so:
Mecanismos de extensibilidade
Elementos para modelar processos e threads
Elementos para modelar distribuio e concorrncia
Padres de desenho e colaboraes
Diagramas de actividade (para modelao de processos de negcio)
Refinamento (para tratar relaes entre diferentes nveis de abstraco)
Interfaces e componentes
Linguagem de restries (Object Contraint Language)
O UML providencia os seguintes tipos de diagramas:
Diagramas de casos de utilizao
Diagramas de classes e diagramas de objectos
Diagramas de comportamento
Diagramas de estado (statechart)
Diagramas de actividades
Diagramas de interaco (diagramas de sequncias e diagramas de colaborao)
Diagramas de arquitectura:
Diagramas de componentes
Diagramas de instalao

4.2 Viso Histrica

A Figura 4.1 d uma viso do enquadramento histrico relativamente ao contexto das
linguagens de modelao de software baseado em objectos e, em particular, do UML.
Na primeira metade da dcada de 1990 assistiu-se a uma proliferao de mtodos e
notaes para modelao segundo a abordagem OO (fase da fragmentao). Por essa
altura percebeu-se a necessidade da existncia de uma linguagem que viesse a tornarse uma norma, que fosse aceite e utilizada largamente pela indstria e pelos ambientes
acadmicos e de investigao.
Surgiram entretanto alguns esforos nesse sentido de normalizao, sendo que o UML
apareceu em 1996 melhor posicionado como a linguagem unificadora de notaes,
diagramas, e formas de representao existentes em diferentes mtodos, em particular
nos mtodos Booch, OMT e OOSE (fase da unificao).

UML, PROCESSOS E F ERRAMENTAS CASE - BETA-BOOK

Out. 98

UML 1.2 e 1.3

Industrializao

Manuteno pelo OMG

Jul. 97

UML 1.1
Submisso ao OMG

Standardizao

UML 1.0

Jan. 97
Jun. 96

UML 0.9

Unificao
UML
Partners

Unified Method 0.8

Out. 95

Booch'93
Outros
mtodos

OMT-2

Fragmentao
Booch'91

OMT-1

OOSE

Figura 4.1: Viso histrica do UML.

Seguiu-se um esforo significativo nessa unificao com contributos de variados

parceiros com vista normalizao no mbito da OMG que ocorreu em 1997 (fase da
estandardizao).
Actualmente assiste-se divulgao e adopo generalizada do UML como a
linguagem de modelao de software segundo a abordagem OO. Assiste-se ao
aparecimento de publicaes especficas sobre UML; de teses, relatrios e artigos
tcnico-cientficos que usam o UML; de ferramentas CASE que suportam o UML, etc.
(fase da industrializao).
H dois aspectos importantes que se obtm com o UML: (1) terminam as diferenas,
geralmente inconsequentes, entre as linguagens de modelao dos anteriores mtodos;
e (2) unifica as distintas perspectivas entre diferentes tipos de sistemas (e.g., negcio
vs. software), fases de um processo e conceitos internos.
Um dos esforos significativos no desenho e na especificao do UML foi torn-lo
extensvel e aberto a futuras evolues, que inevitavelmente iro ocorrer. O objectivo
que seja possvel estender o UML sem ser necessrio redefinir o seu ncleo principal.

4.3 Tipos de Elementos Bsicos

A estrutura de conceitos do UML razoavelmente abrangente consistindo num conjunto
variado de notaes, as quais podem ser aplicados em diferentes domnios de
problemas e a diferentes nveis de abstraco. A estrutura de conceitos do UML pode
ser vista atravs das seguintes noes: (1) coisas ou elementos bsicos, com base
nos quais se definem os modelos; (2) relaes, que relacionam elementos; e (3)
diagramas, que agrupam elementos.

CENTRO ATLNTICO - COLECO T ECNOLOGIAS

Os elementos encontram-se organizadas consoante a sua funcionalidade ou

responsabilidade. Assim h elementos de estrutura, comportamento, agrupamento e de
anotao
A Figura 4.2. ilustra o conjunto dos principais elementos de estrutura: classes, classes
activas, interfaces, casos de utilizao, actores, colaboraes, componentes e ns.

Classe

ClasseActiva

Interface

Caso de
Utilizao

Actor

Colaborao

Componente

Figura 4.2: Resumo dos elementos de estrutura.

A Figura 4.3 ilustra outros elementos bsicos do UML, elementos de comportamento

(estados e mensagens), de agrupamento (pacotes) e de anotao (anotaes ou
notas).
Comportamento

Agrupamento

Anotao

estado
Pacote
mensagem

isto uma
anotao

Figura 4.3: Resumo dos elementos de comportamento, agrupamento e anotao.

4.4 Tipos de Relaes

As relaes so conceitos gerais que apresentam uma sintaxe (i.e., neste caso uma
notao) e uma semntica bem definida e que permite o estabelecimento de
interdependncias entre os elementos bsicos acima introduzidos.
A Figura 4.4 ilustra os principais tipos de relaes do UML, nomeadamente relaes do
tipo associao, dependncia, realizao, generalizao e transio de estado. (Mais
abaixo ser descrito em detalhe a semntica e aplicao destes diferentes tipos de
relaes.)

UML, PROCESSOS E F ERRAMENTAS CASE - BETA-BOOK

associao
0--1
tem

*
vive

dependncia

realizao

transio de estado
generalizao

Figura 4.4: Resumo dos tipos de relaes standard.

4.5 Tipos de Diagramas

Os diagramas so conceitos que traduzem a possibilidade de agrupar elementos
bsicos e suas relaes de uma forma lgica ou de uma forma estrutural. H diferentes
tipos de diagramas em UML. Em cada tipo de diagrama usado um subconjunto dos
elementos bsicos acima descritos com diferentes tipos de relaes que tenha sentido
existir.
Por exemplo, um diagrama de classes UML composto por um conjunto de cones
representantes de classes, conjunta e opcionalmente pela representao explcita das
suas relaes.
Com base no quatro princpio de modelao enumerado no Captulo 2 (P4. Nenhum
modelo suficiente por si s. Qualquer sistema no-trivial melhor representado
atravs de pequeno nmero de modelos razoavelmente independentes.), o UML define
diferentes tipos de diagramas, cuja utilizao e aplicao permitem dar vises
complementares.
Diagramas de casos de utilizao, que representa a viso do sistema na perspectiva do
seu utilizador.
Diagramas de classes que permitem especificar a estrutura esttica de um sistema
segundo a abordagem baseada em objectos.
Diagramas de interaco entre objectos (diagramas de sequncias e diagramas de
colaborao) e diagramas de transio de estados e diagramas de actividades, que
permitem especificar a dinmica ou o comportamento de um sistema segundo a
abordagem baseada em objectos.
Diagramas de componentes e diagramas de instalao, que do uma viso da
disposio dos componentes fsicos, software e hardware, de um sistema.

4.5.1 Diagramas de Casos de Utilizao

Um diagrama de casos de utilizao descreve a relao entre actores e casos de
utilizao de um dado sistema (ver exemplo da Figura 4.5). Este um diagrama que
permite dar uma viso global e de alto nvel do sistema, sendo fundamental a definio
correcta da sua fronteira.

CENTRO ATLNTICO - COLECO T ECNOLOGIAS

<<abstract>>
Consulta
Consulta
Lista Membros

Consulta
Termos Oficiais
Consulta
Lista Referncias

Utilizador Annimo

Figura 4.5: Exemplo de um diagrama de casos de utilizao.

Estes diagramas so utilizados preferencialmente na fase de especificao de
requisitos e na modelao de processos de negcio.
Estes diagramas so equivalentes aos homlogos existentes no mtodo OOSE de Ivar
Jacobson [Jac92].

4.5.2 Diagramas de Modelao da Estrutura

Os diagramas de classes do UML so uma integrao de diferentes diagramas de
classes existentes, nomeadamente no OMT [RBP+91], Booch [Boo94] e outros mtodos
OO. Extenses especficas de determinados processos (e.g. recorrendo a esteretipos
e correspondentes cones) podem ser definidos em vrios diagramas para suportarem
diferentes estilos de modelao.
Termo
ingles : String
portugues : String
dataAceitacao : Date
1
1
Proposta
validade : Integer
estado : {pendente, aceite, naoAceite}
data : Date

autor

0..
0..*

1
*

discute
*

Membro
nome : String
morada : string
email : String
instituicao : String
username : String
password : String
recebePropostas : Boolean
recebeDiscussoes : Boolean

Controversia
data : Date
concorda : Boolean
mensagem : String

Figura 4.6: Exemplo de um diagrama de classes.

UML, PROCESSOS E F ERRAMENTAS CASE - BETA-BOOK

Os diagramas de classes (ver exemplo da Figura 4.6) descrevem a estrutura esttica de

um sistema, em particular as entidades existentes, as suas estruturas internas, e
relaes entre si.
Um diagrama de objectos descreve um conjunto de instncias compatveis com
determinado diagrama de classes. Permitem ilustrar os detalhes de um sistema em
determinado momento ao providenciarem cenrios de possveis configuraes.

4.5.3 Diagramas de Modelao do Comportamento

Interaco entre Objectos
Um padro de interaco entre objectos representado por diagramas de interaco,
os quais apresentam duas formas complementares, cada qual focando um aspecto
distinto: diagramas de sequncias e diagramas de colaborao.
Diagramas de Sequncias
Os diagramas de sequncias ilustram interaces entre objectos num determinado
perodo de tempo (ver exemplo da Figura 4.7). Em particular, os objectos so
representados pelas suas linhas de vida e interagem por troca de mensagens ao longo
de um determinado perodo de tempo.

:WebDEI

bdDEI:BDDEI

:UDocente

validarAcesso(login, pwd)
aPwd= obterPwd(login)
[aPwd == pwd]
f= obterUIRegistarEvento()

f.preencherFormulrio

submeterEvento(info)
validarEvento(info)
guardarRegistoEvento()
notificarSucesso()

Figura 4.7: Exemplo de um diagrama de sequncias.

CENTRO ATLNTICO - COLECO T ECNOLOGIAS

Este tipo de diagrama baseia-se numa variedade de diagramas homlogos existentes

em distintos mtodos OO, segundo diferentes designaes, como por exemplo
interaction diagrams, message sequence charts, message trace, event trace, etc.

Diagramas de Colaborao
Os diagramas de colaborao ilustram interaces entre objectos com nfase para a
representao das ligaes entre objectos. Como os diagramas de colaborao no
mostram o tempo como um elemento explcito (tal como acontece nos diagramas de
sequncias), a sequncia de mensagens e de actividades concorrentes determinada
usando-se nmeros sequenciais, com diferentes nveis hierrquicos. Colaboraes so
entidades de modelao principais e constituem geralmente a base para a
representao visual de padres de desenho (design patterns) [GHJV94].
Este tipo de diagrama foi adoptado, entre outros, a partir do diagrama de objectos de
Booch [Boo94], e do diagrama de interaces de objectos de Fusion [MCL+96].

Diagramas de Transio de Estado

Os diagramas de transio de estado descrevem as sequncias de estados que um
objecto ou uma interaco pode passar ao longo da sua existncia em resposta a
estmulos recebidos, conjuntamente com as suas respostas e aces.
So baseados nos statecharts de David Harel com pequenas adaptaes [Har87,
HN96, HG96].

Diagramas de Actividades
Os diagramas de actividade (ver exemplo da Figura 4.8) so um caso particular dos
diagramas de transio de estado, no qual a maioria dos estados so estados
correspondentes a aces e/ou actividades, e no qual as transies so
desencadeadas devido concluso de aces nos estados originais.
O objectivo deste diagrama representar os fluxos conduzidos por processamento
interno, em contraste com eventos externos representados tipicamente nos diagramas
de estado.
Este tipo de diagramas podem ser encarados como um caso particular de diagramas de
estado e inspirados nos diagramas de workflow, fluxogramas ou naqueles baseados em
SDL (Specification and Description Language) [ITU93].

UML, PROCESSOS E F ERRAMENTAS CASE - BETA-BOOK

Cliente

Gestor Comercial

Pedir
Proposta

Gestor Produo

Registar
Briefing
:Oramento
[aberto]
Registar
Oramento
:Oramento
[preparao
]
Preparar Oramento
(info Comercial)

Fechar Oramento

[exige info de produo]

Preparar Oramento
(info Produo)

:Oramento
[fechado]

Preparar Proposta
Receber
Proposta

Figura 4.8: Exemplo de um diagrama de actividades.

4.5.4 Diagramas de Arquitectura

Os diagramas de arquitectura descrevem aspectos da fase de implementao de um
sistema de software, por exemplo, relativamente estrutura e dependncias de
mdulos de cdigo fonte e de mdulos executveis. Estes diagramas apresentam-se
sob duas formas: diagramas de componentes e diagramas de instalao.

Diagramas de componentes
Os diagramas de componentes descrevem as dependncias entre componentes de
software, incluindo componentes de cdigo fonte, cdigo binrio e executveis.
Os diagramas de componentes so representados na forma de tipos e no na forma de
instncias. Para descrever-se instncias de componentes, usam-se os diagramas de
instalao.

Diagramas de Instalao
Os diagramas de instalao (deployment diagrams) descrevem a configurao de
elementos de suporte de processamento, e de componentes de software, processos e
objectos existentes nesses elementos (ver exemplo da Figura 4.9).

CENTRO ATLNTICO - COLECO T ECNOLOGIAS

10
PC
Web browser

Java GUI

<<device>>
Consola

Clientes
Servidor
Web

*
<<device>

Modem

*
Internet <<device>
Modem

RMI

Servidor

JDBC-ODBC Servidor
BD

Workstation Linux
Apache
Servlets:
VerificaPassword
ObtemTermos
ObtemReferencias
...

Figura 4.9: Exemplo de um diagrama de instalao.

4.6 Mecanismos Comuns

O UML contm um conjunto de mecanismos comuns que so aplicados de modo
consistente ao longo dos seus diferentes diagramas. Descreve-se de seguida dois dos
mecanismos comuns mais usados: anotaes e mecanismos de extensibilidade.

4.6.1 Notas (Anotaes)

Notas ou anotaes so os adornos mais importantes que existem autonomamente
(i.e., sem estarem directamente associados a outros elementos). Ver-se- mais frente
a utilizao de outros adornos (por exemplo, adornos para qualificar elementos
participantes em relaes).
Uma nota ilustra um comentrio e no tem qualquer impacto semntico, no sentido que
o seu contedo no altera o significado do modelo no qual ela se encontra (ver Figuras
4.9 e 4.10). Por isso normal a utilizao de notas para se descrever informalmente:
requisitos, restries, observaes, revises ou explicaes.
Considerar a aplicao do
padro de desenho
Singleton e Factory.

Ver http://www.objectspace.com
para mais informao sobre o ORB

alb. 2000/6/12

Figura 4.10: Exemplo de notas.

Em geral devem ser tomadas em considerao as seguintes observaes na utilizao
de notas:
Localizao: Devem ser colocadas graficamente perto dos elementos que descrevem.
Visibilidade: Podem-se esconder ou tornar visveis (isto dependendo das ferramentas
de suporte).

UML, PROCESSOS E F ERRAMENTAS CASE - BETA-BOOK

11

Extenso: Devem-se usar referncias (e.g., nomes de documentos ou URL) caso se

pretenda um comentrio mais extenso.
Evoluo: H medida que o modelo evolui, as notas antigas (que deixem de ter sentido)
devem ser eliminadas dos modelos.

4.6.2 Mecanismos de Extensibilidade

O UML providencia os seguintes mecanismos que permitem estender a sua linguagem
de forma consistente: esteretipos, marcas e restries. Ver-se- no Captulo 9 (UML
Aspectos Avanados) mais detalhes sobre este assunto. Interessa desde j referir
alguns aspectos na aplicao destes mecanismos, designadamente deve-se:
Introduzir um nmero reduzido destes elementos.
Escolher nomes curtos e com significado para esteretipos e marcas.
Sempre que a preciso puder ser relaxada, usar texto livre para especificao das
restries. Caso contrrio, usar a linguagem OCL. O OCL (Object Constraint Language)
[WK99] uma linguagem para especificao formal de restries e parte integrante do
UML [OMG99].
A definio destes mecanismos de extensibilidade do UML, em particular a introduo
de esteretipos, deve ser realizada por um nmero restrito de especialistas da empresa
e deve ser devidamente documentado.

Esteretipos
Um esteretipo um metatipo, isto , um tipo que descreve tipos. Permite definir novos
tipos de elementos no metamodelo do UML, e por conseguinte permite estender o UML.
O nome de um esteretipo representado entre os caracteres e . Exemplos:
Na modelao de processos de negcio: trabalhador, documento, poltica.
Na modelao de aplicaes especficas: classes de interface, controlo, e
entidade.
Na modelao de aplicaes Web, usando o Web Application Extension [Con00]):
classes de Server Page, Client Page, Form, Select Element.

esteretipo exception
com nome e icon
esteretipo com nome

metaclass
ModelElement

exception
Overflow !

esteretipo
boundary com icon

SensorTemperatura
Figura 4.11: Exemplo de esteretipos.

CENTRO ATLNTICO - COLECO T ECNOLOGIAS

12

A Figura 4.11 ilustra trs formas complementares de apresentao de esteretipos: com

cone (e.g., SensorTemperatura); com nome (e.g., ModelElement); e com nome e
cone (e.g., Overflow).
A definio de um esteretipo tem de ter em conta os seguintes aspectos:
Propriedades (pode providenciar o seu prprio conjunto de marcas)
Semntica (pode providenciar a sua prprias restries)
Notao (pode providenciar o seu prprio cone)
A classe base do metamodelo que vai ser estendida (i.e., se o esteretipo estende uma
classe, uma associao, uma componente, etc.)

Marcas com Valor

Cada elemento em UML tem um conjunto de propriedades. Por exemplo: as classes
tm um nome, uma lista de atributos e uma lista de operaes; as associaes tm um
nome e dois ou mais elementos participantes. Enquanto que os esteretipos permitem
adicionar novos elementos ao UML, as marcas com valor permitem adicionar novas
propriedades aos elementos, quer sejam elementos j existentes no UML, quer sejam
elementos definidos em novos esteretipos.
Uma marca com valor deve ser entendido como metadata (isto , dados que descrevem
dados) pois o seu valor aplica-se ao prprio elemento e no s suas instncias. Por
exemplo, conforme ilustrado na Figura 4.12, pode-se especificar o nmero de
processadores instalados em cada tipo de n, ou pode-se especificar se um
determinado componente para ser instalado/usado com perfil de cliente, servidor, ou
ambos.
marca com valor
marca sem valor

Servidor
{processador=3}

library
Trans.dll
{serverOnly}

Figura 4.12: Exemplo de marcas com valor.

Um par marca e valor delimitado entre os caracteres { e }. Exemplos de
aplicaes usuais:
Para gerao de cdigo: E.g.: {language=Java}, {linker=Blinker}
Na produo automtica de documentao
Na gesto de configuraes: E.g.: {autor=AMRS}, {data=...}

Restries
Qualquer elemento em UML tem necessariamente uma determinada semntica. As
restries (contraints) permitem adicionar ou alterar a semntica assumida por omisso.
Uma restrio consiste na especificao de uma condio delimitada pelos caracteres
{ e }. A condio pode ser especificada numa linguagem formal (e.g., OCL) ou
informal (e.g., texto em portugus).

UML, PROCESSOS E F ERRAMENTAS CASE - BETA-BOOK

13
Exemplo 2

Exemplo 1

Departamento
0..1
marido

Pessoa
gnero:{m, f}

{self.mulher.genero=f and
self.marido.genero=m}

{subset}
0..1
mulher

restrio formal
usando OCL

membro

1..*

gestor

Pessoa

Figura 4.13: Exemplos de utilizao de restries.

Uma restrio permite especificar condies que tm de ser validadas para que o
modelo seja bem definido. Por exemplo, como especificar que uma pessoa pode
estar casada apenas com outra pessoa do sexo oposto? A Figura 4.13 ilustra como
especificar em OCL essa restrio (Exemplo 1), bem como especificar que uma pessoa
para ser gestor de um departamento tem tambm de ser, necessariamente, membro
desse departamento (Exemplo 2).

4.7 Organizao dos Artefactos - Pacotes

Um pacote (package) em UML um elemento meramente organizacional. Permite
agregar diferentes elementos de um sistema em grupos de forma que semntica ou
estruturalmente faa sentido agreg-los.
Um pacote pode conter outros elementos, incluindo: classes, interfaces, componentes,
ns, casos de utilizao, e mesmo outros pacotes. Por outro lado, um elemento
encontra-se definido em apenas um nico pacote.
A necessidade da existncia de pacotes torna-se evidente na modelizao de sistemas
de mdia/grande dimenso, em que se torna impossvel modeliz-los de uma s vez
por razes de ordem prtica. Os principais benefcios da sua utilizao so: (1) facilita a
gesto e procura de artefactos; (2) evita os conflitos de nomes (e.g., X::A diferente de
X::Y:A, e diferente de Z::A); e (3) providencia um mecanismo de controlo de acessos
(visibilidade).
Elementos de diferentes tipos podem ter o mesmo nome dentro de um pacote. Por
exemplo, pode existir num pacote uma classe e uma componente com o nome
Entidade. Contudo, de modo a reduzir-se possveis confuses, sugere-se que tal
prtica no seja adoptada.

4.7.1 Representao Grfica

Em UML os pacotes so representados graficamente por uma pasta (tabbed folder) com
duas zonas complementares: um pequeno rectngulo (designado por tabulador ou tab),
normalmente com o nome do pacote; e um rectngulo maior onde normalmente se
especificam os elementos constituintes desse pacote ou, pelo menos, os seus
elementos pblicos.

CENTRO ATLNTICO - COLECO T ECNOLOGIAS

14

Utilizadores
nomes simples

(1)

+UAnnimo
+URegistado
-Utilizador

(2)
package (DEI) dentro de
outro package (Docentes)

Regras de Negcio

(3)
DEI::Docentes
{version=1.4}

DEI

DEI
Docentes
{version=1.4}

=
Docentes

Figura 4.14: Exemplos de pacotes.

A Figura 4.14 ilustra alguns exemplos de representao de pacotes. No exemplo (1) o
pacote tem o nome Utilizadores e descreve os seus elementos. Os smbolos +, -
e # representam informao de visibilidade, respectivamente visibilidade pblica,
privada e protegida (ver abaixo para mais detalhes).
O exemplo (2) ilustra uma forma alternativa de representar um pacote em que no so
apresentados os seus elementos. O nome do pacote Regras de Negcio e
encontra-se colocado no meio do rectngulo maior.
Por fim, o exemplo (3) ilustra dois aspectos interessantes. Por um lado, a possibilidade
de relaes de hierarquia ou aninhamento entre pacotes: o pacote Docentes est
contido no pacote DEI e pode ser identificado univocamente pela concatenao dos
vrios nomes separados pelo smbolo ::. Outro aspecto interessante a possibilidade
de caracterizar o pacote atravs dos mecanismos comuns discutidos na Seco 4.6,
tais como especificao de marcas (e.g., {version=1.4}), esteretipos ou
restries.

4.7.2 Relaes entre Pacotes

Os pacotes apresentam entre si diferentes tipos de relaes, em particular relaes de
importao, exportao e generalizao.

Visibilidade
Os smbolos +, - e #, semelhana do que acontece na especificao de atributos
e operaes de classes, permite indicar o tipo de visibilidade que os elementos
constituintes de um pacote apresentam.
Um elemento com visibilidade pblica (+) significa que esse elemento pode ser
usado/referenciado por qualquer outro elemento independentemente do local onde
definido.
Um elemento com visibilidade privada (-) significa que esse elemento apenas pode ser
usado/referenciado por elementos definidos no mesmo pacote.

UML, PROCESSOS E F ERRAMENTAS CASE - BETA-BOOK

15

Um elemento com visibilidade protegida (#) significa que esse elemento pode ser
usado/referenciado por um elemento definido no mesmo pacote ou num outro pacote
que seja uma especializao (atravs da relao de herana) do primeiro.
semelhana do que acontece com algumas linguagens de programao (e.g., C++)
relativamente relao entre classes, possvel definir-se uma relao de friend entre
dois pacotes ( uma relao de dependncia entre pacotes, com esteretipo friend).
Neste caso, um pacote que friend de outro pode aceder/referenciar todos os seus
elementos independentemente da sua visibilidade. Contudo este tipo de dependncia
deve ser evitado sempre que possvel porque viola os princpios do encapsulamento e
da minimizao de dependncias.

Importao e Exportao
Um pacote exporta, por definio, todos os seus elementos pblicos. Mas tal facto no
implica que um elemento definido noutro pacote possa aceder/referenciar a um
elemento exportado num outro pacote. Por exemplo, o elemento DataBase exportado
no pacote DataServer no pode ser referenciado por qualquer elemento definido em
WebDEI (ver Figura 4.15). Para que tal pudesse ocorrer deveria existir explicitamente
uma relao de importao entre esses dois pacotes.
DataServer

WebDEI

+DataBase
+LoggingService

+HomePage
+DocentesPage
-BrokerPage

exportao

DEIServlets
+HomeServlet
+ DocentesServlet
-AbstractServlet

import

importao
javax::servlets::http

import

Figura 4.15: Relaes de importao/exportao entre pacotes.

A relao de importao uma relao de dependncia (linha dirigida a tracejado) com
esteretipo import. Por exemplo, o pacote WebDEI importa (todos os elementos
pblicos definidos em) DEIServlets, e este por sua vez importa todos os elementos
pblicos definidos em javax::serlets::http.
Note-se que a relao de importao no transitiva. No exemplo da Figura 4.14, o
WebDEI importa DEIServlets, e este importa javax::serlets::http, no entanto
WebDEI no importa o javax::serlets::http. Isto significa que os elementos
definidos em WebDEI podem aceder aos elementos pblicos de DEIServlets, mas
no aos de javax::serlets::http. Para que tal fosse possvel, dever-se-ia definir
explicitamente uma relao de importao entre esses dois pacotes.

CENTRO ATLNTICO - COLECO T ECNOLOGIAS

16

Note-se por fim que a relao de importao no inversa. Ou seja, o facto dos
elementos definidos em WebDEI poderem aceder aos elementos pblicos de
DEIServlets no implica que o inverso seja verdade.
Preferencialmente, os elementos exportados por cada pacote devem ver do tipo
interface j que as interfaces providenciam uma interface de programao sem
revelarem os detalhes de implementao e as relaes de classes definidas
internamente no respectivo pacote.

Generalizao
A relao de generalizao entre pacotes semelhante homloga relativamente a
classes, e usada para se especificar famlias de pacotes, tpicas em sistemas
complexos ou flexveis (e.g., significativamente parametrizveis, multi-plataforma, multilinguagem).
WebServer
+Page
+Form
#EventHandler
generalizao

Servlets
+Page
+Form
#EventHandler
+HttpServlet

ASP

Figura 4.16: Relaes de generalizao entre pacotes.

A Figura 4.16 ilustra uma relao de generalizao entre pacotes. O pacote WebServer
tem duas classes pblicas (Page e Form) e uma protegida (EventHandler) e
especializado por dois pacotes distintos: Servlets, que especializa o pacote de topo
segundo a tecnologia da Sun (Java Servlets); e ASP, que providencia a mesma
funcionalidade segundo a tecnologia da Microsoft (Active Server Pages).

4.7.3 Tipos de Pacotes

Na generalidade dos exerccios acadmicos a dimenso e/ou a simplicidade do
problema faz com que um pacote seja simplesmente um pacote. Contudo, em
situaes reais de modelao de sistemas de software de mdia/grande dimenso,
realizada por equipas de vrios indivduos, torna-se necessrio tipificar os prprios
pacotes.
A especificao actual do UML prope cinco esteretipos standard aplicados a pacotes:
system: pacote que representa o sistema inteiro; este pacote agrega/aninha
tipicamente pacotes dos restantes tipos (subsistema, fachada, etc.).
subsystem: pacote que representa uma parte constituinte do sistema inteiro.

UML, PROCESSOS E F ERRAMENTAS CASE - BETA-BOOK

17

facade: pacote com elementos (tipicamente classes e interfaces) que constituem a

fachada (ou a interface de programao) providenciada conjunta e coerentemente por
outros pacotes. A fachada permite esconder os detalhes de arquitectura e de
implementao de vrios elementos eventualmente organizados em distintos pacotes.
Os elementos definidos numa fachada apenas referem outros elementos definidos
noutros pacotes.
framework: um framework uma arquitectura de classes e interfaces com inmeros
pontos de variabilidade ou extensibilidade e com estruturas de objectos padronizadas,
conhecidas por padres de desenho. O desenvolvimento de sistemas baseados em
frameworks e em componentes de software um tpico emergente extremamente
actual.
stub: um adaptador (stub) usado quando se pretende partir um sistema em
diferentes pacotes por motivos de diviso de trabalho, quer em termos fsicos/espaciais,
quer em termos temporais. Os adaptadores permitem que duas equipas consigam
trabalhar paralelamente em diferentes locais, mas mantendo algum nvel de
interdependncia.
Em geral os pacotes mais usados so do tipo sistema e subsistema, podendo contudo,
surgir situaes em que um pacote claramente do tipo fachada, adaptador ou
framework. Por omisso assume-se que um pacote do tipo sistema (se for de primeiro
nvel) e subsistema (se fr de segundo ou mais nvel).

4.7.4 Modelao de Grupos de Elementos

Compete a cada processo de desenvolvimento de software formalizar ou dar sugestes
relativamente forma de organizar todo o processo atravs de uma estrutura adequada
de pacotes. Este aspecto analisado na Parte 3 do livro.
Refere-se no entanto algumas das formas clssicas de organizao dos artefactos de
um projectos em termos de pacotes:
Organizao por casos de utilizao: Esta a aproximao, por exemplo, do ICONIX
em que o sistema e respectivos modelos se encontram distribudos por pacotes,
consoante os vrios casos de utilizao.
Organizao por tipos de modelos: Esta a aproximao, por exemplo, do RUP em que
o sistema se encontra dividido por diferentes pacotes consoante os tipos de modelos
produzidos. H por exemplo, um pacote (com uma eventual hierarquia de sub-pacotes
aninhados) para o modelo de casos de utilizao; outro para o modelo de anlise; outro
para o modelo de desenho; e outro ainda para o modelo de implementao.
Um aspecto correlacionado com o anterior, na definio e gesto dos pacotes e dos
seus correspondentes artefactos o esforo no sentido da minimizao das
dependncias entre si, assim como na minimizao de dependncias dentre os
respectivos artefactos.