Breve Introduo aos Diagramas da UML

Este artigo apresenta resumidamente os diagramas da UML (Unified Modeling Language), a linguagem
padronizada pela OMG (Object Management Group) para representar sistemas orientados a objeto. Cada
diagramas apresentado separadamente, monstrando a !is"o do sistema #ue ele objeti!a descre!er. $ seguir
discute%se como estes diagramas se integram para descre!er um sistema de soft&are.
Uma linguagem e no um mtodo
$pesar da UML ser 'oje a linguagem padr"o para se descre!er sistemas orientados a objeto, n"o correto
se referir ( UML como um mtodo para desen!ol!imento de soft&are. )"o se encontra na UML a descri*"o
de passos #ue se de!e seguir para se desen!ol!er um sistema, nem mesmo #uais s"o as etapas para se
modelar um sistema. $ UML se limita, e+clusi!amente, a representar um sistema atra!s de um conjunto de
diagramas, onde cada diagrama se refere a uma !is"o parcial do sistema, #ue em conjunto forma um todo
integrado e coerente. Os diagramas da UML s"o apresentados na tabela abai+o,
Diagrama de comportamento externo
-iagrama de Casos de Uso
Diagramas de comportamento interno
-iagrama de Classes
-iagrama de .acotes
Diagramas estruturais
-iagrama de /e#01ncia de E!ento
-iagrama de Colabora*"o
-iagrama de Estados
Diagramas de implementao
-iagrama de Componentes
-iagrama de -istribui*"o
Diferentes Vises do Sistema
$ UML permite ao analista representar o sistema seguindo diferentes !is2es. Cada !is"o possui uma grande
depend1ncia das outras !is2es, garantindo assim a coer1ncia e completeza do modelo, e conse#0entemente do
sistema de soft&are. $ rela*"o entre os diagramas de!e ser garantida pelo projetista mas n"o assegurada pela
UML. Este trabal'o estuda a rela*"o entre os diagramas de modo a garantir #ue o sistema projetado pelo
conjunto de diagramas seja coerente.
Os diagramas podem ser agrupados segundo aspectos da !is"o #ue proporcionam em,
Diagrama de comportamento externo, #ue d"o uma !is"o e+terna do sistema e dos objeti!os
#ue os atores e+ternos tem do sistema.
Diagramas estruturais #ue d"o uma !is"o est3tica da estrutura de suporte do sistema, sobre a
#ual ele ser3 constru4do.
Diagramas de comportamento interno, #ue tratam dos processos #ue ocorrem entre as
estruturas #ue comp2em o sistema e d"o uma !is"o da din5mica interna do sistema, e
Diagramas de implementao #ue descre!em como estas estruturas s"o implementadas em
soft&are e 'ard&are.
$ figura a seguir mostra como os diagramas podem se integrar para descre!er um sistema. $pesar de n"o
propor um mtodo, e+iste na UML uma intera*"o forte entre os diagramas como mostra as setas da figura
acima. Esta figura n"o faz parte da UML mas pode ajudar a na!ega*"o entre os diagramas.
Figura 1. Relaes entre os diagramas da UML
Cada diagrama formado por elementos e liga*2es entre os elementos. 6anto os elementos como as liga*2es
podem possuir propriedades #ue os caracterizam e definem, como nomes, multiplicidades e outros adornos.
/egue%se uma descri*"o indi!idual de cada diagrama. $s descri*2es abai+o foram baseadas nos trabal'os de
$mbler (7889) e :urlan (7889), com e+emplos e+tra4dos do tutorial de UML apresentado por -eboni (7889)
onde desen!ol!ido um sistema de gerenciamento de uma biblioteca !irtual.
Diagrama de asos de Uso
Um caso de uso descre!e um objeti!o #ue um ator e+terno ao sistema tem com o sistema. Um ator pode ser um
elemento 'umano ou n"o #ue interage com o sistema. O ator se encontra fora do escopo de atua*"o do sistema,
en#uanto #ue o conjunto de casos de uso formam o escopo do sistema. $ lin'a #ue separa os atores dos casos de
uso a fronteira do sistema.
O diagrama de casos de uso representa graficamente esta intera*"o, e define o conte+to do sistema. Os atores
s"o representados por representa*2es simplificadas de uma figura 'umana, en#uanto os casos de uso s"o elipses
contendo cada uma o nome de um caso de uso. Os atores se comunicam com os casos de uso, #ue
representado por uma lin'a unindo os dois elementos. Uma seta pode, opcionalmente, representar o flu+o
principal de informa*"o nesta intera*"o e ajudar a leitura do caso de uso.
Figura 2. Exemplo de Casos de Uso
Como os casos de uso representam um objeti!o do ator comum dar como nome aos casos de uso frases !erbais
curtas no infiniti!o (EmprestarMaterial) ou no ger;ndio ( EmprestandoMaterial) onde o sujeito normalmente o
ator. E+.
O usu3rio empresta material
O usu3rio pes#uisa assunto
Cada caso de uso de!e receber uma descri*"o te+tual #ue permita o entendimento do objeti!o. Esta descri*"o
pode ser detal'ada em cen3rios. Um cen3rio uma inst5ncia de um caso de uso, isto , uma situa*"o onde o
ator utilizou o sistema para conseguir atingir o objeti!o do caso de uso. Um cen3rio pode ser considerado
otimista de o ator obte!e sucesso no seu objeti!o, pode ser pessimista se o ator n"o conseguiu e ocorreu uma
situa*"o de e+ce*"o, ou o cen3rio pode ser alternati!o, #uanto frente a uma situa*"o de e+ce*"o o ator optou por
camin'os alternati!os. $ssim para cada caso de uso pode se descre!er um te+to com,
Cen3rios Otimistas
Cen3rios .essimistas
Cen3rios $lternati!os
para descre!er os processos en!ol!idos no caso de uso.
Diagrama de lasses
Os diagramas de classe descre!em as classes #ue formam a estrutura do sistema e suas rela*2es. $s rela*2es
entre as classes podem ser associa*2es, agrega*2es ou 'eran*as. $s classes possuem alm de um nome, os
atributos e as opera*2es #ue desempen'am para o sistema. Uma rela*"o indica um tipo de depend1ncia entre as
classes, essa depend1ncia pode ser forte com no caso da 'eran*a ou da agrega*"o ou mais fraca como no caso da
associa*"o, mas indicam #ue as classes relacionadas cooperam de alguma forma para cumprir um objeti!o para
o sistema.
/endo uma linguagem de descri*"o, a UML permite diferentes n4!eis de abstra*"o aos diagramas, dependendo
da etapa do desen!ol!imento do sistema em #ue se encontram. $ssim, os diagramas de classe podem e+ibir nas
fases iniciais da an3lise apenas o nome das classes, e em uma fase seguinte os atributos e opera*2es (como
mostra a figura abai+o). :inalmente, em uma fase a!an*ada do projeto pode e+ibir os tipos dos atributos, a
!isibilidade, a multiplicidade das rela*2es e di!ersas restri*2es. E+istem elementos na UML para todas estas
representa*2es..
Figura 3. Exemplo de um Diagrama de Classes
O diagrama de classes, ao final do processo de modelagem, pode ser traduzido em uma estrutura de c<digo #ue
ser!ir3 de base para a implementa*"o do sistema. Obser!a%se, no entanto, #ue n"o e+iste no diagrama de classes
uma informa*"o sobre os algoritmos #ue ser"o utilizados nas opera*2es, e tambm n"o se pode precisar a
din5mica do sistema por#ue n"o '3 elementos sobre o processo ou a se#01ncia de processamento neste modelo.
Estas informa*2es s"o representadas em outros diagramas, como os diagramas de se#01ncia de e!entos ou
diagramas de estado.
Diagrama de !acotes
Em muitos casos um ;nico diagrama de classes pode ser e+ageradamente grande para representar todo o
sistema. $ssim con!eniente utilizar%se de um elemento para organizar os subsistemas do modelo. .ara isto
utiliza%se os diagramas de pacote. Um pacote representa um grupo de classes (ou outros elementos) #ue se
relacionam com outros pacotes atra!s de uma rela*"o de depend1ncia. Um diagrama de pacotes pode ser
utilizado em #ual#uer fase do processo de modelagem e !isa organizar os modelos.
)a figura o pacote de classes das janelas #ue cuida da interface da aplica*"o dependente funcionalmente das
classes de neg<cio para cumprirem suas ati!idades.
Figura 4. Exemplo de um Diagrama de a!otes
Diagrama de Se"#$ncia de %ventos
Os casos de uso, como !imos, representam conjuntos de cen3rios #ue descre!em os diferentes processos #ue
ocorrem no sistema. O diagrama de se#01ncia de e!entos permite modelar estes processos atra!s da troca de
mensagens (e!entos) entre os objetos do sistema. Os objetos s"o representados por lin'as !erticais e as
mensagens como setas #ue partem do objeto #ue in!oca um outro objeto. $s setas podem ser c'eias para indicar
uma mensagem de c'amada ou tracejadas para indicar uma mensagem de retorno. $ figura abai+o mostra um
e+emplo deste diagrama, onde pode%se obser!ar #ue o tempo segue o ei+o !ertical de cima para bai+o. -e!em
ser desen'ados tantos diagramas de se#01ncia #uantos cen3rios foram le!antados nos diagramas de casos de
uso.
Figura ". Exemplo de um Diagrama de #e$%&n!ia de E'entos
Cada mensagem no diagrama de se#01ncia de e!entos corresponde a uma opera*"o no diagrama de classes.
Como as mensagens s"o opera*2es in!ocadas, elas de!em estar presentes nos objeto de destino, #ue s"o ati!adas
pelas mensagens no objeto de origem.
Diagrama de ola&orao
Os diagramas de colabora*"o possuem, essencialmente, a mesma informa*"o #ue um diagrama de se#01ncia de
e!entos, mas #ue apresentada de uma outra forma. Este diagrama tambm mostra as mensagens sendo
trocadas entre as classes, mas agora em um diagrama onde s"o apresentados os relacionamentos entre as classes,
ser!indo de camin'o para as mensagens. Os diagramas de colabora*"o tambm ser!em para descre!er os
cen3rios identificados pelos casos de uso, e podem ser tra*ados em conjunto com o diagrama de classes.
Figura (. Exemplo de um diagrama de Cola)ora*o
$ figura mostra um diagrama de colabora*"o e nele !emos a numera*"o utilizada para facilitar a leitura e
identificar a ordem em #ue as mensagens s"o trocadas. $ numera*"o decimal indica a se#01ncia de uma
mensagem e os s4mbolos %= e >% a dire*"o. Os diagramas de colabora*"o mostram o processo #ue n"o aparece
nos diagramas de classe.
Diagrama de %stados
Os diagramas de transi*"o de estados mostram a din5mica interna de uma classe. $penas os e!entos e estados
de uma ;nica classe s"o apresentados neste diagrama. Entende%se por e!entos os fatos #ue ocorrem em uma
classe, pro!ocados por elementos e+ternos (mensagens) ou internos como condi*2es internas da classe #ue
pro!ocam uma troca de estado. Uma classe pode ter !3rios estados, caracterizados por situa*2es em #ue a classe
se encontra. Os diagramas de estados podem possuir ainda estados especiais como o estado inicial e o estado
final e outros estados de controle internos.
Figura +. Exemplo de um Diagrama de ,ransi*o de Estados
$nalogamente ao diagrama de classes poss4!el se e+trair um c<digo e+ecut3!el de um diagrama de estados,
em uma linguagem de programa*"o. ?dentificando condi*2es, la*os de repeti*"o e c'amadas de opera*2es
internas ou e+ternas (mensagens) nos estados de espera e nas transi*2es de estado (e!entos).
Diagrama de omponentes
Os diagramas de componentes mostram os elementos reutiliz3!eis de soft&are e sua interdepend1ncia. Um
componente formado por um conjunto de classes #ue se encontram implementadas nele. Um componente,
assim como as classes #ue ele possui, dependem funcionalmente das classes de outro componente. O diagrama
de componentes mostra esta depend1ncia. )o diagrama de componentes tambm poss4!el mostrar a
configura*"o de um sistema de soft&are mostrando, graficamente, a depend1ncia entre os di!ersos ar#ui!os #ue
comp2em o sistema.
Figura -. Exemplo de um Diagrama de Componentes
Diagrama de Distri&uio
Os diagramas de distribui*"o mostram a distribui*"o de 'ard&are do sistema, identificando os ser!idores como
n<s do diagrama e a rede #ue relaciona os n<s. Os componentes de soft&are !"o estar mapeados nestes n<s.
Figura .. Exemplo de um Diagrama de Distri)ui*o
@elacionamento dos diagramas
Os diagramas da UML s"o inter%relacionados por#ue descre!em o mesmo sistema. Um primeiro n4!el de
relacionamento foi apresentado na figura 7 deste trabal'o onde os diagramas foram organizados segundo a !is"o
do sistema #ue cada um promo!e. )esta organiza*"o os diagramas se integram para apresentar uma !is"o
completa do sistema. )o entanto !amos !er como os elementos dos diagramas se integram.
)o #ue diz respeito a implementa*"o '3 um perfeito entendimento em como uma classe mapeada em
componentes de soft&are e estes em n<s de uma rede. O e+emplo abai+o representa o modelo de uma p3gina na
internet, mapeada no seu diret<rio e este no seu n<. $ p3gina tanto pode ser entendida como uma classe isolada
ou como um componente.
Figura 1/. Mapeamento de um URL pela UML 0De)oni1 1...2
Os diagramas da UML necessitam ainda de um maior n4!el de integra*"o para garantir a integridade do modelo.
Esta integra*"o feita relacionando%se as mensagens trocadas entre as classes com a opera*2es de uma classe,
com os e!entos #ue ocorrem internamente ( classes. .ara entender estas rela*2es !amos analisar a figura 77.
)esta figura temos uma !is"o tridimensional da integra*"o dos diagramas da UML. Aemos #ue o diagrama de
classe forma a base para os demais diagramas, cada classe possui um (ou mais) diagramas de estado #ue trocam
e!entos entre si, alguns e!entos in!ocam e!entos remotos de outras classe, ao #ue c'amaremos de mensagens.
Estas mensagens podem ser descritas no diagrama de se#01ncia de e!entos ou no diagrama de colabora*"o.

Figura 11. 3is*o tridimensional da integra*o da UML
oncluso
Um fator importante para a integridade do modelo #ue tanto as mensagens como os e!entos encontrem nas
classes a opera*"o #ue a implementa. Uma opera*"o pode in!ocar mais de uma mensagem, assim como pode
participar de mais de um e!ento. Mas de!e 'a!er estar rela*"o. O uso correto de nomes, par5metros permite
controlar esta coer1ncia do modelo. $ssim recomendado manter atualizado o dicion3rio do modelo de classe e
um gloss3rio de termos do sistema. .ara um uso eficaz da UML necess3rio se aprofundar no con'ecimento dos
diagramas e do #ue cada elemento representa, lembrando%se sempre em manter uma coer1ncia de conceitos.
rditos, 4os5 Eduardo 6indel De)oni

Bi&liografia
$mblerB /cott. Co& t'e UML Models :it 6oget'er. /oft&are -e!elopment magazine.(na internet,
&&&.sdmagazine.comDuml) 7889.
:urlan, Eos -a!i. Modelagem de Objetos atra!s da UML% t'e Unified Modeling Language. /"o .aulo,
MaFron GooFs, 7889.
-eboni, Eos Eduardo Hindel. 6utorial de UML, /UCE/U% /. COM-EI, 89. (.ublicado na internet em
&&&.!o++el.com.brDtutuml) 7889.
-eboni, Eos Eduardo Hindel. Modelando a Jeb com a UML. $presentado no Objetos -istribuidos 88. /"o
.aulo.