1.

2.
3.
4.
5.

6.
7.
8.

9.

10.
11.
12.

13.

Introduo
Desenvolvimento de Softwares orientado a objetos
UML A unificao dos mtodos para a criao de um novo padro
Uso da UML
Fases do Desenvolvimento de um Sistema em UML
1. Anlise de Requisitos
2. Anlise
3. Design (Projeto)
4. Programao
5. Testes
A Notao da Linguagem de Modelagem Unificada UML
Vises
Modelos de Elementos
1. Classes
2. Objetos
3. Estados
4. Pacotes
5. Componentes
6. Relacionamentos
7. Mecanismos Gerais
Diagramas
1. Diagrama Use-Case
2. Diagrama de Classes
3. Diagrama de Objetos
4. Diagrama de Estado
5. Diagrama de Sequncia
6. Diagrama de Colaborao
7. Diagrama de Atividade
8. Diagrama de Componente
9. Diagrama de Execuo
Um processo para utilizar a UML
O Futuro da UML
Um estudo de caso em UML - Sistema de Controle de Contas Correntes, Poupana e
Aplicaes Pr-fixadas
1. Anlise de Requisitos
2. Anlise
3. Design
4. Implementao
5. Testes
Concluso

1. Introduo
O grande problema do desenvolvimento de novos sistemas utilizando a orientao a objetos nas
fases de anlise de requisitos, anlise de sistemas e design que no existe uma notao
padronizada e realmente eficaz que abranja qualquer tipo de aplicao que se deseje. Cada
simbologia existente possui seus prprios conceitos, grficos e terminologias, resultando numa
grande confuso, especialmente para aqueles que querem utilizar a orientao a objetos no s
sabendo para que lado aponta a seta de um relacionamento, mas sabendo criar modelos de
qualidade para ajud-los a construir e manter sistemas cada vez mais eficazes.
Quando a "Unified Modeling Language" (UML) foi lanada, muitos desenvolvedores da rea da
orientao a objetos ficaram entusiasmados j que essa padronizao proposta pela UML era o
tipo de fora que eles sempre esperaram.
A UML muito mais que a padronizao de uma notao. tambm o desenvolvimento de novos
conceitos no normalmente usados. Por isso e muitas outras razes, o bom entendimento da UML
no apenas aprender a simbologia e o seu significado, mas tambm significa aprender a modelar
orientado a objetos no estado da arte.
UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que so conhecidos
como "os trs amigos". Eles possuem uma extenso conhecimento na rea de modelagem
orientado a objetos j que as trs mais conceituadas metodologias de modelagem orientado a
objetos foram eles que desenvolveram e a UML a juno do que havia de melhor nestas trs
metodologias adicionado novos conceitos e vises da linguagem. Veremos caractersticas de cada
uma destas metodologias no desenvolver deste trabalho.
Veremos como a UML aborda o carter esttico e dinmico do sistema a ser analisado levando em
considerao, j no perodo de modelagem, todas as futuras caractersticas do sistema em relao
a utilizao de "packages" prprios da linguagem a ser utilizada, utilizao do banco de dados bem
como as diversas especificaes do sistema a ser desenvolvido de acordo com as mtricas finais
do sistema.
No intuito deste trabalho definir e explicar os significados de classes, objetos, relacionamentos,
fluxos, mensagens e outras entidades comuns da orientao a objetos, e sim apresentarmos como
essas entidades so criadas, simbolizadas, organizadas e como sero utilizadas dentro de um
desenvolvimento utilizando a UML.

2. Desenvolvimento de Softwares orientado a objetos

Os conceitos da orientao a objetos j vm sido discutidos h muito tempo, desde o lanamento
da 1 linguagem orientada a objetos, a SIMULA. Vrios "papas" da engenharia de software mundial
como Peter Coad, Edward Yourdon e Roger Pressman abordaram extensamente a anlise
orientada a objetos como realmente um grande avano no desenvolvimento de sistemas. Mas
mesmo assim, eles citam que no existe (ou que no existia no momento de suas publicaes)
uma linguagem que possibilitasse o desenvolvimento de qualquer software utilizando a anlise
orientada a objetos.
Os conceitos que Coad, Yourdon, Pressman e tantos outros abordaram, discutiram e definiram em
suas publicaes foram que:

A orientao a objetos uma tecnologia para a produo de modelos que especifiquem o

domnio do problema de um sistema.

Quando construdos corretamente, sistemas orientados a objetos so flexveis a

mudanas, possuem estruturas bem conhecidas e provm a oportunidade de criar e
implementar componentes totalmente reutilizveis.

Modelos orientado a objetos so implementados convenientemente utilizando uma

linguagem de programao orientada a objetos. A engenharia de software orientada a
objetos muito mais que utilizar mecanismos de sua linguagem de programao, saber
utilizar da melhor forma possvel todas as tcnicas da modelagem orientada a objetos..

A orientao a objetos no s teoria, mas uma tecnologia de eficincia e qualidade

comprovadas usada em inmeros projetos e para construo de diferentes tipo de
sistemas.

A orientao a objetos requer um mtodo que integre o processo de desenvolvimento e a

linguagem de modelagem com a construo de tcnicas e ferramentas adequadas

3. UML A unificao dos mtodos para a criao de um novo padro

A UML uma tentativa de padronizar a modelagem orientada a objetos de uma forma que qualquer
sistema, seja qual for o tipo, possa ser modelado corretamente, com consistncia, fcil de se
comunicar com outras aplicaes, simples de ser atualizado e compreensvel.
Existem vrias metodologias de modelagem orientada a objetos que at o surgimento da UML
causavam uma guerra entre a comunidade de desenvolvedores orientado a objetos. A UML acabou
com esta guerra trazendo as melhores idias de cada uma destas metodologias, e mostrando
como deveria ser a migrao de cada uma para a UML.
Falaremos sobre algumas das principais metodologias que se tornaram populares nos anos 90:

Booch O mtodo de Grady Booch para desenvolvimento orientado a objetos est

disponvel em muitas verses. Booch definiu a noo de que um sistema analisado a
partir de um nmero de vises, onde cada viso descrita por um nmero de modelos e
diagramas. O Mtodo de Booch trazia uma simbologia complexa de ser desenhada a mo,
continha tambm o processo pelo qual sistemas so analisados por macro e micro vises.

OMT Tcnica de Modelagem de Objetos (Object Modelling Technique) um mtodo

desenvolvido pela GE (General Electric) onde James Rumbaugh trabalhava. O mtodo
especialmente voltado para o teste dos modelos, baseado nas especificaes da anlise
de requisitos do sistema. O modelo total do sistema baseado no mtodo OMT composto
pela juno dos modelos de objetos, funcional e use-cases.

OOSE/Objectory Os mtodos OOSE e o Objectory foram desenvolvidos baseados no

mesmo ponto de vista formado por Ivar Jacobson. O mtodo OOSE a viso de Jacobson
de um mtodo orientado a objetos, j o Objectory usado para a construo de sistemas
to diversos quanto eles forem. Ambos os mtodos so baseados na utilizao de usecases, que definem os requisitos iniciais do sistema, vistos por um ator externo. O mtodo
Objectory tambm foi adaptado para a engenharia de negcios, onde usado para
modelar e melhorar os processos envolvidos no funcionamento de empresas.

Cada um destes mtodos possui sua prpria notao (seus prprios smbolos para representar
modelos orientado a objetos), processos (que atividades so desenvolvidas em diferentes partes
do desenvolvimento), e ferramentas (as ferramentas CASE que suportam cada uma destas
notaes e processos).
Diante desta diversidade de conceitos, "os trs amigos", Grady Booch, James Rumbaugh e Ivar
Jacobson decidiram criar uma Linguagem de Modelagem Unificada. Eles disponibilizaram
inmeras verses preliminares da UML para a comunidade de desenvolvedores e a resposta
incrementou muitas novas idias que melhoraram ainda mais a linguagem.
Os objetivos da UML so:

A modelagem de sistemas (no apenas de software) usando os conceitos da orientao a

objetos;

Estabelecer uma unio fazendo com que mtodos conceituais sejam tambm executveis;

Criar uma linguagem de modelagem usvel tanto pelo homem quanto pela mquina.

A UML est destinada a ser dominante, a linguagem de modelagem comum a ser usada nas
indstrias. Ela est totalmente baseada em conceitos e padres extensivamente testados
provenientes das metodologias existentes anteriormente, e tambm muito bem documentada
com toda a especificao da semntica da linguagem representada em meta-modelos

4. Uso da UML
A UML usada no desenvolvimento dos mais diversos tipos de sistemas. Ela abrange sempre
qualquer caracterstica de um sistema em um de seus diagramas e tambm aplicada em
diferentes fases do desenvolvimento de um sistema, desde a especificao da anlise de
requisitos at a finalizao com a fase de testes.
O objetivo da UML descrever qualquer tipo de sistema, em termos de diagramas orientado a
objetos. Naturalmente, o uso mais comum para criar modelos de sistemas de software, mas a
UML tambm usada para representar sistemas mecnicos sem nenhum software. Aqui esto
alguns tipos diferentes de sistemas com suas caractersticas mais comuns:

Sistemas de Informao: Armazenar, pesquisar, editar e mostrar informaes para os

usurios. Manter grandes quantidades de dados com relacionamentos complexos, que so
guardados em bancos de dados relacionais ou orientados a objetos.

Sistemas Tcnicos: Manter e controlar equipamentos tcnicos como de telecomunicaes,

equipamentos militares ou processos industriais. Eles devem possuir interfaces especiais
do equipamento e menos programao de software de que os sistemas de informao.
Sistemas Tcnicos so geralmente sistemas real-time.

Sistemas Real-time Integrados: Executados em simples peas de hardware integrados a

telefones celulares, carros, alarmes etc. Estes sistemas implementam programao de
baixo nvel e requerem suporte real-time.

Sistemas Distribudos: Distribudos em mquinas onde os dados so transferidos

facilmente de uma mquina para outra. Eles requerem mecanismos de comunicao
sincronizados para garantir a integridade dos dados e geralmente so construdos em
mecanismos de objetos como CORBA, COM/DCOM ou Java Beans/RMI.

Sistemas de Software: Definem uma infra-estrutura tcnica que outros softwares utilizam.
Sistemas Operacionais, bancos de dados, e aes de usurios que executam aes de
baixo nvel no hardware, ao mesmo tempo que disponibilizam interfaces genricas de uso
de outros softwares.

Sistemas de Negcios: descreve os objetivos, especificaes (pessoas, computadores

etc.), as regras (leis, estratgias de negcios etc.), e o atual trabalho desempenhado nos
processos do negcio.

importante perceber que a maioria dos sistemas no possuem apenas uma destas
caractersticas acima relacionadas, mas vrias delas ao mesmo tempo. Sistemas de informaes
de hoje, por exemplo, podem ter tanto caractersticas distribudas como real-time. E a UML suporta
modelagens de todos estes tipos de sistemas.

5. Fases do Desenvolvimento de um Sistema em UML

Existem cinco fases no desenvolvimento de sistemas de software: anlise de requisitos, anlise,
design (projeto), programao e testes. Estas cinco fases no devem ser executadas na ordem
descrita acima, mas concomitantemente de forma que problemas detectados numa certa fase
modifiquem e melhorem as fases desenvolvidas anteriormente de forma que o resultado global
gere um produto de alta qualidade e performance. A seguir falaremos sobre cada fase do
desenvolvimento de um sistema em UML:
5.1. Anlise de Requisitos
Esta fase captura as intenes e necessidades dos usurios do sistema a ser desenvolvido atravs
do uso de funes chamadas "use-cases". Atravs do desenvolvimento de "use-case", as
entidades externas ao sistema (em UML chamados de "atores externos") que interagem e
possuem interesse no sistema so modelados entre as funes que eles requerem, funes estas
chamadas de "use-cases". Os atores externos e os "use-cases" so modelados com
relacionamentos que possuem comunicao associativa entre eles ou so desmembrados em
hierarquia. Cada "use-case" modelado descrito atravs de um texto, e este especifica os
requerimentos do ator externo que utilizar este "use-case". O diagrama de "use-cases" mostrar o
que os atores externos, ou seja, os usurios do futuro sistema devero esperar do aplicativo,
conhecendo toda sua funcionalidade sem importar como esta ser implementada. A anlise de
requisitos tambm pode ser desenvolvida baseada em processos de negcios, e no apenas para
sistemas de software.
5.2. Anlise
A fase de anlise est preocupada com as primeiras abstraes (classes e objetos) e mecanismos
que estaro presentes no domnio do problema. As classes so modeladas e ligadas atravs de
relacionamentos com outras classes, e so descritas no Diagrama de Classe. As colaboraes
entre classes tambm so mostradas neste diagrama para desenvolver os "use-cases" modelados
anteriormente, estas colaboraes so criadas atravs de modelos dinmicos em UML. Na anlise,
s sero modeladas classes que pertenam ao domnio principal do problema do software, ou seja,
classes tcnicas que gerenciem banco de dados, interface, comunicao, concorrncia e outros
no estaro presentes neste diagrama.
5.3. Design (Projeto)
Na fase de design, o resultado da anlise expandido em solues tcnicas. Novas classes sero
adicionadas para prover uma infra-estrutura tcnica: a interface do usurio e de perifricos,
gerenciamento de banco de dados, comunicao com outros sistemas, dentre outros. As classes
do domnio do problema modeladas na fase de anlise so mescladas nessa nova infra-estrutura
tcnica tornando possvel alterar tanto o domnio do problema quanto a infra-estrutura. O design
resulta no detalhamento das especificaes para a fase de programao do sistema.
5.4. Programao
Na fase de programao, as classes provenientes do design so convertidas para o cdigo da
linguagem orientada a objetos escolhida (a utilizao de linguagens procedurais extremamente
no recomendada). Dependendo da capacidade da linguagem usada, essa converso pode ser

uma tarefa fcil ou muito complicada. No momento da criao de modelos de anlise e design em
UML, melhor evitar traduzi-los mentalmente em cdigo. Nas fases anteriores, os modelos criados
so o significado do entendimento e da estrutura do sistema, ento, no momento da gerao do
cdigo onde o analista conclua antecipadamente sobre modificaes em seu contedo, seus
modelos no estaro mais demonstrando o real perfil do sistema. A programao uma fase
separada e distinta onde os modelos criados so convertidos em cdigo.
5.5. Testes
Um sistema normalmente rodado em testes de unidade, integrao, e aceitao. Os testes de
unidade so para classes individuais ou grupos de classes e so geralmente testados pelo
programador. Os testes de integrao so aplicados j usando as classes e componentes
integrados para se confirmar se as classes esto cooperando uma com as outras como
especificado nos modelos. Os testes de aceitao observam o sistema como uma " caixa preta" e
verificam se o sistema est funcionando como o especificado nos primeiros diagramas de "usecases".
O sistema ser testado pelo usurio final e verificar se os resultados mostrados esto realmente
de acordo com as intenes do usurio final.

6. A Notao da Linguagem de Modelagem Unificada UML

Tendo em mente as cinco fases do desenvolvimento de softwares, as fases de anlise de
requisitos, anlise e design utilizam-se em seu desenvolvimento cinco tipos de vises, nove tipos
de diagramas e vrios modelos de elementos que sero utilizados na criao dos diagramas e
mecanismos gerais que todos em conjunto especificam e exemplificam a definio do sistema,
tanto a definio no que diz respeito funcionalidade esttica e dinmica do desenvolvimento de
um sistema.
Antes de abordarmos cada um destes componentes separadamente, definiremos as partes que
compem a UML:

Vises: As Vises mostram diferentes aspectos do sistema que est sendo modelado. A
viso no um grfico, mas uma abstrao consistindo em uma srie de diagramas.
Definindo um nmero de vises, cada uma mostrar aspectos particulares do sistema,
dando enfoque a ngulos e nveis de abstraes diferentes e uma figura completa do
sistema poder ser construda. As vises tambm podem servir de ligao entre a
linguagem de modelagem e o mtodo/processo de desenvolvimento escolhido.

Modelos de Elementos: Os conceitos usados nos diagramas so modelos de elementos

que representam definies comuns da orientao a objetos como as classes, objetos,
mensagem, relacionamentos entre classes incluindo associaes, dependncias e
heranas.

Mecanismos Gerais: Os mecanismos gerais provm comentrios suplementares,

informaes, ou semntica sobre os elementos que compem os modelos; eles provm
tambm mecanismos de extenso para adaptar ou estender a UML para um
mtodo/processo, organizao ou usurio especfico.

Diagramas: Os diagramas so os grficos que descrevem o contedo em uma viso. UML

possui nove tipo de diagramas que so usados em combinao para prover todas as
vises do sistema.

10

7. Vises
O desenvolvimento de um sistema complexo no uma tarefa fcil. O ideal seria que o sistema
inteiro pudesse ser descrito em um nico grfico e que este representasse por completo as reais
intenes do sistema sem ambiguidades, sendo facilmente interpretvel. Infelizmente, isso
impossvel. Um nico grfico incapaz de capturar todas as informaes necessrias para
descrever um sistema.
Um sistema composto por diversos aspectos: funcional (que sua estrutura esttica e suas
interaes dinmicas), no funcional (requisitos de tempo, confiabilidade, desenvolvimento, etc.) e
aspectos organizacionais (organizao do trabalho, mapeamento dos mdulos de cdigo, etc.).
Ento o sistema descrito em um certo nmero de vises, cada uma representando uma projeo
da descrio completa e mostrando aspectos particulares do sistema.
Cada viso descrita por um nmero de diagramas que contm informaes que do nfase aos
aspectos particulares do sistema. Existe em alguns casos uma certa sobreposio entre os
diagramas o que significa que um deste pode fazer parte de mais de uma viso. Os diagramas que
compem as vises contm os modelos de elementos do sistema. As vises que compem um
sistema so:

Viso "use-case": Descreve a funcionalidade do sistema desempenhada pelos atores

externos do sistema (usurios). A viso use-case central, j que seu contedo base do
desenvolvimento das outras vises do sistema. Essa viso montada sobre os diagramas
de use-case e eventualmente diagramas de atividade.

Viso Lgica: Descreve como a funcionalidade do sistema ser implementada. feita

principalmente pelos analistas e desenvolvedores. Em contraste com a viso use-case, a
viso lgica observa e estuda o sistema internamente. Ela descreve e especifica a
estrutura esttica do sistema (classes, objetos, e relacionamentos) e as colaboraes
dinmicas quando os objetos enviarem mensagens uns para os outros para realizarem as

11

funes do sistema. Propriedades como persistncia e concorrncia so definidas nesta

fase, bem como as interfaces e as estruturas de classes. A estrutura esttica descrita
pelos diagramas de classes e objetos. O modelamento dinmico descrito pelos
diagramas de estado, sequencia, colaborao e atividade.

Viso de Componentes: uma descrio da implementao dos mdulos e suas

dependncias. principalmente executado por desenvolvedores, e consiste nos
componentes dos diagramas.

Viso de concorrncia: Trata a diviso do sistema em processos e processadores. Este

aspecto, que uma propriedade no funcional do sistema, permite uma melhor utilizao
do ambiente onde o sistema se encontrar, se o mesmo possui execues paralelas, e se
existe dentro do sistema um gerenciamento de eventos assncronos. Uma vez dividido o
sistema em linhas de execuo de processos concorrentes (threads), esta viso de
concorrncia dever mostrar como se d a comunicao e a concorrncia destas threads.
A viso de concorrncia suportada pelos diagramas dinmicos, que so os diagramas de
estado, sequencia, colaborao e atividade, e pelos diagramas de implementao, que so
os diagramas de componente e execuo.

Viso de Organizao: Finalmente, a viso de organizao mostra a organizao fsica do

sistema, os computadores, os perifricos e como eles se conectam entre si. Esta viso
ser executada pelos desenvolvedores, integradores e testadores, e ser representada
pelo diagrama de execuo.

12

8. Modelos de Elementos
Os conceitos usados nos diagramas so chamados de modelos de elementos. Um modelo de
elemento definido com a semntica, a definio formal do elemento com o exato significado do
que ele representa sem definies duvidosas ou ambguas e tambm define sua representao
grfica que mostrada nos diagramas da UML. Um elemento pode existir em diversos tipos de
diagramas, mas existem regras que definem que elementos podem ser mostrados em que tipos de
diagramas. Alguns exemplos de modelos de elementos so as classes, objetos, estados, pacotes e
componentes. Os relacionamentos tambm so modelos de elementos, e so usados para
conectar outros modelos de elementos entre si. Todos os modelos de elementos sero definidos e
exemplificados a seguir.
8.1. Classes
Uma classe a descrio de um tipo de objeto. Todos os objetos so instncias de classes, onde a
classe descreve as propriedades e comportamentos daquele objeto. Objetos s podem ser
instanciados de classes. Usam-se classes para classificar os objetos que identificamos no mundo
real. Tomando como exemplo Charles Darwin, que usou classes para classificar os animais
conhecidos, e combinou suas classes por herana para descrever a "Teoria da Evoluo". A
tcnica de herana entre classes tambm usada em orientao a objetos.
Uma classe pode ser a descrio de um objeto em qualquer tipo de sistema sistemas de
informao, tcnicos, integrados real-time, distribudos, software etc. Num sistema de software, por
exemplo, existem classes que representam entidades de software num sistema operacional como
arquivos, programas executveis, janelas, barras de rolagem, etc.
Identificar as classes de um sistema pode ser complicado, e deve ser feito por experts no domnio
do problema a que o software modelado se baseia. As classes devem ser retiradas do domnio do
problema e serem nomeadas pelo que elas representam no sistema. Quando procuramos definir
as classes de um sistema, existem algumas questes que podem ajudar a identific-las:

Existem informaes que devem ser armazenadas ou analisadas? Se existir alguma

informao que tenha que ser guardada, transformada ou analisada de alguma forma,
ento uma possvel candidata para ser uma classe.

Existem sistemas externos ao modelado? Se existir, eles devero ser vistos como classes
pelo sistema para que possa interagir com outros externos.

Existem classes de bibliotecas, componentes ou modelos externos a serem utilizados pelo

sistema modelado? Se sim, normalmente essas classes, componentes e modelos contero
classes candidatas ao nosso sistema.

Qual o papel dos atores dentro do sistema? Talvez o papel deles possa ser visto como
classes, por exemplo, usurio, operador, cliente e da por diante.

Em UML as classes so representadas por um retngulo dividido em trs compartimentos: o

compartimento de nome, que conter apenas o nome da classe modelada, o de atributos, que

13

possuir a relao de atributos que a classe possui em sua estrutura interna, e o compartimento de
operaes, que sero o mtodos de manipulao de dados e de comunicao de uma classe com
outras do sistema. A sintaxe usada em cada um destes compartimentos independente de
qualquer linguagem de programao, embora pode ser usadas outras sintaxes como a do C++,
Java, e etc.

8.2. Objetos
Um objeto um elemento que podemos manipular, acompanhar seu comportamento, criar, destruir
etc. Um objeto existe no mundo real. Pode ser uma parte de qualquer tipo de sistema, por
exemplo, uma mquina, uma organizao, ou negcio. Existem objetos que no encontramos no
mundo real, mas que podem ser vistos de derivaes de estudos da estrutura e comportamento de
outros objetos do mundo real.
Em UML um objeto mostrado como uma classe s que seu nome (do objeto) sublinhado, e o
nome do objeto pode ser mostrado opcionalmente precedido do nome da classe.

8.3. Estados
Todos os objetos possuem um estado que significa o resultado de atividades executadas pelo
objeto, e normalmente determinada pelos valores de seus atributos e ligaes com outros
objetos.
Um objeto muda de estado quando acontece algo, o fato de acontecer alguma coisa com o objeto
chamado de evento. Atravs da anlise da mudana de estados dos tipos de objetos de um
sistema, podemos prever todos os possveis comportamentos de um objetos de acordo com os
eventos que o mesmo possa sofrer.

14

Um estado, em sua notao, pode conter trs compartimentos. O primeiro mostra o nome do
estado. O segundo opcional e mostra a varivel do estado, onde os atributos do objeto em
questo podem ser listados e atualizados. Os atributos so aqueles mostrados na representao
da classe, e em algumas vezes, podem ser mostradas tambm as variveis temporrias, que so
muito teis em diagramas de estado, j que atravs da observncia de seus valores podemos
perceber a sua influncia na mudana de estados de um objeto. O terceiro compartimento
opcional e chamado de compartimento de atividade, onde eventos e aes podem ser listadas.
Trs eventos padres podem ser mostrados no compartimento de atividades de um estado: entrar,
sair e fazer. O evento entrar pode ser usado para definir atividades no momento em que o objeto
entra naquele estado. O evento sair, define atividades que o objeto executa antes de passar para o
prximo estado e o evento fazer define as atividades do objeto enquanto se encontra naquele
estado.
8.4. Pacotes
Pacote um mecanismo de agrupamento, onde todos os modelos de elementos podem ser
agrupados. Em UML, um pacote definido como: "Um mecanismo de propsito geral para
organizar elementos semanticamente relacionados em grupos." Todos os modelos de elementos
que so ligados ou referenciados por um pacote so chamados de "Contedo do pacote". Um
pacote possui vrios modelos de elementos, e isto significa que estes no podem ser includos em
outros pacotes.

Pacotes podem importar modelos de elementos de outros pacotes. Quando um modelo de

elemento importado, refere-se apenas ao pacote que possui o elemento. Na grande maioria dos

15

casos, os pacotes possuem relacionamentos com outros pacotes. Embora estes no possuam
semnticas definidas para suas instncias. Os relacionamentos permitidos entre pacotes so de
dependncia, refinamento e generalizao (herana).
O pacote tem uma grande similaridade com a agregao (relacionamento que ser tratado em
seguida). O fato de um pacote ser composto de modelos de elementos cria uma agregao de
composio. Se este for destrudo, todo o seu contedo tambm ser.
8.5. Componentes
Um componente pode ser tanto um cdigo em linguagem de programao como um cdigo
executvel j compilado. Por exemplo, em um sistema desenvolvido em Java, cada arquivo .java
ou .class um componente do sistema, e ser mostrado no diagrama de componentes que os
utiliza.

8.6. Relacionamentos
Os relacionamentos ligam as classes/objetos entre si criando relaes lgicas entre estas
entidades. Os relacionamentos podem ser dos seguintes tipos:

Associao: uma conexo entre classes, e tambm significa que uma conexo entre
objetos daquelas classes. Em UML, uma associao definida com um relacionamento
que descreve uma srie de ligaes, onde a ligao definida como a semntica entre as
duplas de objetos ligados.

Generalizao: um relacionamento de um elemento mais geral e outro mais especfico.

O elemento mais especfico pode conter apenas informaes adicionais. Uma instncia
(um objeto uma instncia de uma classe) do elemento mais especfico pode ser usada
onde o elemento mais geral seja permitido.

Dependncia e Refinamentos: Dependncia um relacionamento entre elementos, um

independente e outro dependente. Uma modificao um elemento independente afetar
diretamente elementos dependentes do anterior. Refinamento um relacionamento entre
duas descries de uma mesma entidade, mas em nveis diferentes de abstrao.

Abordaremos agora cada tipo de relacionamento e suas respectivas sub-divises:

16

8.6.1 Associaes
Uma associao representa que duas classes possuem uma ligao (link) entre elas, significando
por exemplo que elas "conhecem uma a outra", "esto conectadas com", "para cada X existe um Y"
e assim por diante. Classes e associaes so muito poderosas quando modeladas em sistemas
complexos.
Associaes Normais
O tipo mais comum de associao apenas uma conexo entre classes. representada por uma
linha slida entre duas classes. A associao possui um nome (junto linha que representa a
associao), normalmente um verbo, mas substantivos tambm so permitidos.
Pode-se tambm colocar uma seta no final da associao indicando que esta s pode ser usada
para o lado onde a seta aponta. Mas associaes tambm podem possuir dois nomes, significando
um nome para cada sentido da associao.
Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos
esto relacionados no link. O intervalo pode ser de zero para um (0..1), zero para vrios (0..* ou
apenas *), um para vrios (1..*), dois (2), cinco para 11 (5..11) e assim por diante. tambm
possvel expressar uma srie de nmeros como (1, 4, 6..12). Se no for descrito nenhuma
multiplicidade, ento considerado o padro de um para um (1..1 ou apenas 1).

No exemplo acima vemos um relacionamento entre as classes Cliente e Conta Corrente se

relacionam por associao.
Associao Recursiva
possvel conectar uma classe a ela mesma atravs de uma associao e que ainda representa
semanticamente a conexo entre dois objetos, mas os objetos conectados so da mesma classe.
Uma associao deste tipo chamada de associao recursiva.

Associao Qualificada
Associaes qualificadas so usadas com associaes de um para vrios (1..*) ou vrios para
vrios (*). O "qualificador" (identificador da associao qualificada) especifica como um
determinado objeto no final da associao "n" identificado, e pode ser visto como um tipo de

17

chave para separar todos os objetos na associao. O identificador desenhado como uma
pequena caixa no final da associao junto classe de onde a navegao deve ser feita.

Associao Exclusiva
Em alguns modelos nem todas as combinaes so vlidas, e isto pode causar problemas que
devem ser tratados. Uma associao exclusiva uma restrio em duas ou mais associaes. Ela
especifica que objetos de uma classe podem participar de no mximo uma das associaes em um
dado momento. Uma associao exclusiva representada por uma linha tracejada entre as
associaes que so parte da associao exclusiva, com a especificao "{ou}" sobre a linha
tracejada.

No diagrama acima um contrato no pode se referir a uma pessoa e a uma empresa ao mesmo
tempo, significando que o relacionamento exclusivo a somente uma das duas classes.
Associao Ordenada
As associaes entre objetos podem ter uma ordem implcita. O padro para uma associao
desordenada (ou sem nenhuma ordem especfica). Mas uma ordem pode ser especificada atravs
da associao ordenada. Este tipo de associao pode ser muito til em casos como este: janelas
de um sistema tm que ser ordenadas na tela (uma est no topo, uma est no fundo e assim por
diante). A associao ordenada pode ser escrita apenas colocando "{ordenada}" junto a linha de
associao entre as duas classes.
Associao de Classe
Uma classe pode ser associada a uma outra associao. Este tipo de associao no conectada
a nenhuma das extremidades da associao j existente, mas na prpria linha da associao. Esta
associao serve para se adicionar informaes extra a associao j existente.

18

A associao da classe Fila com a associao das classes Cliente e Processo pode ser estendida
com operaes de adicionar processos na fila, para ler e remover da fila e de ler o seu tamanho.
Se operaes ou atributos so adicionados a associao, ela deve ser mostrada como uma classe.
Associao Ternria
Mais de duas classes podem ser associadas entre si, a associao ternria associa trs classes.
Ela mostrada como um grade losango (diamante) e ainda suporta uma associao de classe
ligada a ela, traaria-se, ento, uma linha tracejada a partir do losango para a classe onde seria
feita a associao ternria.

No exemplo acima a associao ternria especifica que um cliente poder possuir 1 ou mais
contratos e cada contrato ser composto de 1 ou vrias regras contratuais.
Agregao
A agregao um caso particular da associao. A agregao indica que uma das classes do
relacionamento uma parte, ou est contida em outra classe. As palavras chaves usadas para
identificar uma agregao so: "consiste em", "contm", " parte de".

Existem tipos especiais de agregao que so as agregaes compartilhadas e as compostas.

Agregao Compartilhada: dita compartilhada quando uma das classes uma parte, ou
est contida na outra, mas esta parte pode fazer estar contida na outra vrias vezes em
um mesmo momento.

19

No exemplo acima uma pessoa pode ser membro de um time ou vrios times e em
determinado momento.

Agregao de Composio: uma agregao onde uma classe que est contida na outra
"vive" e constitui a outra. Se o objeto da classe que contm for destrudo, as classes da
agregao de composio sero destrudas juntamente j que as mesmas fazem parte da
outra.

8.6.2. Generalizaes
A generalizao um relacionamento entre um elemento geral e um outro mais especfico. O
elemento mais especfico possui todas as caractersticas do elemento geral e contm ainda mais
particularidades. Um objeto mais especfico pode ser usado como uma instncia do elemento mais
geral. A generalizao, tambm chamada de herana, permite a criao de elementos
especializados em outros.
Existem alguns tipos de generalizaes que variam em sua utilizao a partir da situao. So
elas: generalizao normal e restrita. As generalizaes restritas se dividem em generalizao de
sobreposio, disjuntiva, completa e incompleta.
Generalizao Normal
Na generalizao normal a classe mais especfica, chamada de subclasse, herda tudo da classe
mais geral, chamada de superclasse. Os atributos, operaes e todas as associaes so
herdadas.

Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa hierarquia
de classes que um grfico onde as classes esto ligadas atravs de generalizaes.
A generalizao normal representada por uma linha entre as duas classes que fazem o
relacionamento, sendo que coloca-se um seta no lado da linha onde encontra-se a superclasse
indicando a generalizao.

20

Generalizao Restrita
Uma restrio aplicada a uma generalizao especifica informaes mais precisas sobre como a
generalizao deve ser usada e estendida no futuro. As restries a seguir definem as
generalizaes restritas com mais de uma subclasse:

Generalizaes de Sobreposio e Disjuntiva: Generalizao de sobreposio significa

que quando subclasses herdam de uma superclasse por sobreposio, novas subclasses
destas podem herdar de mais de uma subclasse. A generalizao disjuntiva exatamente
o contrrio da sobreposio e a generalizao utilizada como padro.

Generalizaes Completa e Incompleta: Uma restrio simbolizando que uma

generalizao completa significa que todas as subclasses j foram especificadas, e no
existe mais possibilidade de outra generalizao a partir daquele ponto. A generalizao
incompleta exatamente o contrrio da completa e assumida como padro da
linguagem.

8.6.3. Dependncia e Refinamentos

Alm das associaes e generalizaes, existem ainda dois tipos de relacionamentos em UML. O
relacionamento de dependncia uma conexo semntica entre dois modelos de elementos, um

21

independente e outro dependente. Uma mudana no elemento independente ir afetar o modelo

dependente. Como no caso anterior com generalizaes, os modelos de elementos podem ser
uma classe, um pacote, um use-case e assim por diante. Quando uma classe recebe um objeto de
outra classe como parmetro, uma classe acessa o objeto global da outra. Nesse caso existe uma
dependncia entre estas duas classes, apesar de no ser explcita.
Uma relao de dependncia simbolizada por uma linha tracejada com uma seta no final de um
dos lados do relacionamento. E sobre essa linha o tipo de dependncia que existe entre as duas
classes. As classes "Amigas" provenientes do C++ so um exemplo de um relacionamento de
dependncia.

Os refinamentos so um tipo de relacionamento entre duas descries de uma mesma coisa, mas
em nveis de abstrao diferentes e podem ser usados para modelar diferentes implementaes de
uma mesma coisa (uma implementao simples e outra mais complexa, mas tambm mais
eficiente).
Os refinamentos so simbolizados por uma linha tracejada com um tringulo no final de um dos
lados do relacionamento e so usados em modelos de coordenao. Em grandes projetos, todos
os modelos que so feitos devem ser coordenados. Coordenao de modelos pode ser usada para
mostrar modelos em diferentes nveis de abstrao que se relacionam e mostram tambm como
modelos em diferentes fases de desenvolvimento se relacionam.

8.7. Mecanismos Gerais

A UML utiliza alguns mecanismos em seus diagramas para tratar informaes adicionais.

Ornamentos: Ornamentos grficos so anexados aos modelos de elementos em

diagramas e adicionam semnticas ao elemento. Um exemplo de um ornamento o da
tcnica de separar um tipo de uma instncia. Quando um elemento representa um tipo, seu
nome mostrado em negrito. Quando o mesmo elemento representa a instncia de um
tipo, seu nome escrito sublinhado e pode significar tanto o nome da instncia quanto o
nome do tipo. Outros ornamentos so os de especificao de multiplicidade de
relacionamentos, onde a multiplicidade um nmero ou um intervalo que indica quantas
instncias de um tipo conectado pode estar envolvido na relao.

Notas: Nem tudo pode ser definido em uma linguagem de modelagem, sem importar o
quanto extensa ela seja. Para permitir adicionar informaes a um modelo no poderia ser
representado de outra forma, UML prov a capacidade de adicionar Notas. Uma Nota pode
ser colocada em qualquer lugar em um diagrama, e pode conter qualquer tipo de
informao.

22

9. Diagramas
Os diagramas utilizados pela UML so compostos de nove tipos: diagrama de use case, de
classes, de objeto, de estado, de sequncia, de colaborao, de atividade, de componente e o de
execuo.
Todos os sistemas possuem uma estrutura esttica e um comportamento dinmico. A UML suporta
modelos estticos (estrutura esttica), dinmicos (comportamento dinmico) e funcional. A
Modelagem esttica suportada pelo diagrama de classes e de objetos, que consiste nas classes
e seus relacionamentos. Os relacionamentos podem ser de associaes, herana (generalizao),
dependncia ou refinamentos. Os modelamentos dinmicos so suportados pelos diagramas de
estado, sequncia, colaborao e atividade. E o modelamento funcional suportado pelos
diagramas de componente e execuo. Abordaremos agora cada um destes tipos de diagrama:
9.1. Diagrama Use-Case
A modelagem de um diagrama use-case uma tcnica usada para descrever e definir os requisitos
funcionais de um sistema. Eles so escritos em termos de atores externos, use-cases e o sistema
modelado. Os atores representam o papel de uma entidade externa ao sistema como um usurio,
um hardware, ou outro sistema que interage com o sistema modelado. Os atores iniciam a
comunicao com o sistema atravs dos use-cases, onde o use-case representa uma sequncia
de aes executadas pelo sistema e recebe do ator que lhe utiliza dados tangveis de um tipo ou
formato j conhecido, e o valor de resposta da execuo de um use-case (contedo) tambm j
de um tipo conhecido, tudo isso definido juntamente com o use-case atravs de texto de
documentao.
Atores e use-cases so classes. Um ator conectado a um ou mais use-cases atravs de
associaes, e tanto atores quanto use-cases podem possuir relacionamentos de generalizao
que definem um comportamento comum de herana em superclasses especializadas em
subclasses.
O uso de use-cases em colaboraes muito importante, onde estas so a descrio de um
contexto mostrando classes/objetos, seus relacionamentos e sua interao exemplificando como
as classes/objetos interagem para executar uma atividade especfica no sistema. Uma colaborao
descrita por diagramas de atividades e um diagrama de colaborao.
Quando um use-case implementado, a responsabilidade de cada passo da execuo deve ser
associada s classes que participam da colaborao, tipicamente especificando as operaes
necessrias dentro destas classes juntamente com a definio de como elas iro interagir. Um

23

cenrio uma instncia de um use-case, ou de uma colaborao, mostrando o caminho especfico

de cada ao. Por isso, o cenrio um importante exemplo de um use-case ou de uma
colaborao. Quando visto a nvel de um use-case, apenas a interao entre o ator externo e o
use-case vista, mas j observando a nvel de uma colaborao, toda as interaes e passos da
execuo que implementam o sistema sero descritos e especificados.

O diagrama de use-cases acima demonstra as funes de um ator externo de um sistema de

controle bancrio de um banco fictcio que foi modelado no estudo de caso no final deste trabalho.
O diagrama especifica que funes o administrador do banco poder desempenhar. Pode-se
perceber que no existe nenhuma preocupao com a implementao de cada uma destas
funes, j que este diagrama apenas se resume a determinar que funes devero ser
suportadas pelo sistema modelado.
9.2 Diagrama de Classes
O diagrama de classes demonstra a estrutura esttica das classes de um sistema onde estas
representam as "coisas" que so gerenciadas pela aplicao modelada. Classes podem se
relacionar com outras atravs de diversas maneiras: associao (conectadas entre si),
dependncia (uma classe depende ou usa outra classe), especializao (uma classe uma
especializao de outra classe), ou em pacotes (classes agrupadas por caractersticas similares).
Todos estes relacionamentos so mostrados no diagrama de classes juntamente com as suas
estruturas internas, que so os atributos e operaes. O diagrama de classes considerado
esttico j que a estrutura descrita sempre vlida em qualquer ponto do ciclo de vida do sistema.
Um sistema normalmente possui alguns diagramas de classes, j que no so todas as classes
que esto inseridas em um nico diagrama e uma certa classes pode participar de vrios
diagramas de classes.

24

Uma classe num diagrama pode ser diretamente implementada utilizando-se uma linguagem de
programao orientada a objetos que tenha suporte direto para construo de classes. Para criar
um diagrama de classes, as classes tm que estar identificadas, descritas e relacionadas entre si.
9.3. Diagrama de Objetos
O diagrama de objetos uma variao do diagrama de classes e utiliza quase a mesma notao. A
diferena que o diagrama de objetos mostra os objetos que foram instanciados das classes. O
diagrama de objetos como se fosse o perfil do sistema em um certo momento de sua execuo.
A mesma notao do diagrama de classes utilizada com 2 excees: os objetos so escritos com
seus nomes sublinhados e todas as instncias num relacionamento so mostradas. Os diagramas
de objetos no so to importantes como os diagramas de classes, mas eles so muito teis para
exemplificar diagramas complexos de classes ajudando muito em sua compreenso. Diagramas de
objetos tambm so usados como parte dos diagramas de colaborao, onde a colaborao
dinmica entre os objetos do sistema so mostrados.

9.4. Diagrama de Estado

O diagrama de estado tipicamente um complemento para a descrio das classes. Este
diagrama mostra todos os estados possveis que objetos de uma certa classe podem se encontrar
e mostra tambm quais so os eventos do sistemas que provocam tais mudanas. Os diagramas

25

de estado no so escritos para todas as classes de um sistema, mas apenas para aquelas que
possuem um nmero definido de estados conhecidos e onde o comportamento das classes
afetado e modificado pelos diferentes estados.
Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e sistemas. Eles mostram
os estados que um objeto pode possuir e como os eventos (mensagens recebidas, timer, erros, e
condies sendo satisfeitas) afetam estes estados ao passar do tempo.

Diagramas de estado possuem um ponto de incio e vrios pontos de finalizao. Um ponto de

incio (estado inicial) mostrado como um crculo todo preenchido, e um ponto de finalizao
(estado final) mostrado como um crculo em volta de um outro crculo menor preenchido. Um
estado mostrado como um retngulo com cantos arredondados. Entre os estados esto as
transies, mostrados como uma linha com uma seta no final de um dos estados. A transio pode
ser nomeada com o seu evento causador. Quando o evento acontece, a transio de um estado
para outro executada ou disparada.
Uma transio de estado normalmente possui um evento ligado a ela. Se um evento anexado a
uma transio, esta ser executada quando o evento ocorrer. Se uma transio no possuir um
evento ligado a ela, a mesma ocorrer quando a ao interna do cdigo do estado for executada
(se existir aes internas como entrar, sair, fazer ou outras aes definidas pelo desenvolvedor).
Ento quando todas as aes forem executadas pelo estado, a transio ser disparada e sero
iniciadas as atividades do prximo estado no diagrama de estados.
9.5. Diagrama de Sequncia
Um diagrama de sequncia mostra a colaborao dinmica entre os vrios objetos de um sistema.
O mais importante aspecto deste diagrama que a partir dele percebe-se a sequncia de
mensagens enviadas entre os objetos. Ele mostra a interao entre os objetos, alguma coisa que
acontecer em um ponto especfico da execuo do sistema. O diagrama de sequncia consiste
em um nmero de objetos mostrado em linhas verticais. O decorrer do tempo visualizado
observando-se o diagrama no sentido vertical de cima para baixo. As mensagens enviadas por
cada objeto so simbolizadas por setas entre os objetos que se relacionam.
Diagramas de sequncia possuem dois eixos: o eixo vertical, que mostra o tempo e o eixo
horizontal, que mostra os objetos envolvidos na sequncia de uma certa atividade. Eles tambm
mostram as interaes para um cenrio especfico de uma certa atividade do sistema.

26

No eixo horizontal esto os objetos envolvidos na sequncia. Cada um representado por um

retngulo de objeto (similar ao diagrama de objetos) e uma linha vertical pontilhada chamada de
linha de vida do objeto, indicando a execuo do objeto durante a sequncia, como exemplo
citamos: mensagens recebidas ou enviadas e ativao de objetos. A comunicao entre os objetos
representada como linha com setas horizontais simbolizando as mensagens entre as linhas de
vida dos objetos. A seta especifica se a mensagem sncrona, assncrona ou simples. As
mensagens podem possuir tambm nmeros sequenciais, eles so utilizados para tornar mais
explcito as sequncia no diagrama.
Em alguns sistemas, objetos rodam concorrentemente, cada um com sua linha de execuo
(thread). Se o sistema usa linhas concorrentes de controle, isto mostrado como ativao,
mensagens assncronas, ou objetos assncronos.

Os diagramas de sequncia podem mostrar objetos que so criados ou destrudos como parte do
cenrio documentado pelo diagrama. Um objeto pode criar outros objetos atravs de mensagens. A
mensagem que cria ou destroi um objeto geralmente sncrona, representada por uma seta slida.
9.6. Diagrama de Colaborao
Um diagrama de colaborao mostra de maneira semelhante ao diagrama de sequencia, a
colaborao dinmica entre os objetos. Normalmente pode-se escolher entre utilizar o diagrama de
colaborao ou o diagrama de sequncia.
No diagrama de colaborao, alm de mostrar a troca de mensagens entre os objetos, percebe-se
tambm os objetos com os seus relacionamentos. A interao de mensagens mostrada em
ambos os diagramas. Se a nfase do diagrama for o decorrer do tempo, melhor escolher o
diagrama de sequncia, mas se a nfase for o contexto do sistema, melhor dar prioridade ao
diagrama de colaborao.
O diagrama de colaborao desenhado como um diagrama de objeto, onde os diversos objetos
so mostrados juntamente com seus relacionamentos. As setas de mensagens so desenhadas
entre os objetos para mostrar o fluxo de mensagens entre eles. As mensagens so nomeadas, que
entre outras coisas mostram a ordem em que as mensagens so enviadas. Tambm podem
mostrar condies, interaes, valores de resposta, e etc. O diagrama de colaborao tambm
pode conter objetos ativos, que executam paralelamente com outros.

27

9.7. Diagrama de Atividade

Diagramas de atividade capturam aes e seus resultados. Eles focam o trabalho executado na
implementao de uma operao (mtodo), e suas atividades numa instncia de um objeto. O
diagrama de atividade uma variao do diagrama de estado e possui um propsito um pouco
diferente do diagrama de estado, que o de capturar aes (trabalho e atividades que sero
executados) e seus resultados em termos das mudanas de estados dos objetos.
Os estados no diagrama de atividade mudam para um prximo estgio quando uma ao
executada (sem ser necessrio especificar nenhum evento como no diagrama de estado). Outra
diferena entre o diagrama de atividade e o de estado que podem ser colocadas como
"swimlanes". Uma swimlane agrupa atividades, com respeito a quem responsvel e onde estas
atividades residem na organizao, e representada por retngulos que englobam todos os
objetos que esto ligados a ela (swimlane).
Um diagrama de atividade uma maneira alternativa de se mostrar interaes, com a possibilidade
de expressar como as aes so executadas, o que elas fazem (mudanas dos estados dos
objetos), quando elas so executadas (sequncia das aes), e onde elas acontecem (swimlanes).
Um diagrama de atividade pode ser usado com diferentes propsitos inclusive:

Para capturar os trabalhos que sero executados quando uma operao disparada
(aes). Este o uso mais comum para o diagrama de atividade.

Para capturar o trabalho interno em um objeto.

Para mostrar como um grupo de aes relacionadas podem ser executadas, e como elas
vo afetar os objetos em torno delas.

Para mostrar como uma instncia pode ser executada em termos de aes e objetos.

Para mostrar como um negcio funciona em termos de trabalhadores (atores), fluxos de

trabalho, organizao, e objetos (fatores fsicos e intelectuais usados no negcio).

O diagrama de atividade mostra o fluxo sequencial das atividades, normalmente utilizado para
demonstrar as atividades executadas por uma operao especfica do sistema. Consistem em
estados de ao, que contm a especificao de uma atividade a ser desempenhada por uma
operao do sistema. Decises e condies, como execuo paralela, tambm podem ser
mostrados na diagrama de atividade. O diagrama tambm pode conter especificaes de
mensagens enviadas e recebidas como partes de aes executadas.

28

9.8. Diagrama de Componente

O diagrama de componente e o de execuo so diagramas que mostram o sistema por um lado
funcional, expondo as relaes entre seus componentes e a organizao de seus mdulos durante
sua execuo.
O diagrama de componente descreve os componentes de software e suas dependncias entre si,
representando a estrutura do cdigo gerado. Os componentes so a implementao na arquitetura
fsica dos conceitos e da funcionalidade definidos na arquitetura lgica (classes, objetos e seus
relacionamentos). Eles so tipicamente os arquivos implementados no ambiente de
desenvolvimento.
Um componente mostrado em UML como um retngulo com uma elipse e dois retngulos
menores do seu lado esquerdo. O nome do componente escrito abaixo ou dentro de seu smbolo.
Componentes so tipos, mas apenas componentes executveis podem ter instncias. Um
diagrama de componente mostra apenas componentes como tipos. Para mostrar instncias de
componentes, deve ser usado um diagrama de execuo, onde as instncias executveis so
alocadas em nodes.
A dependncia entre componentes pode ser mostrada como uma linha tracejada com uma seta,
simbolizando que um componente precisa do outro para possuir uma definio completa. Com o
diagrama de componentes facilmente visvel detectar que arquivos .dll so necessrios para
executar a aplicao.

29

Componentes podem definir interfaces que so visveis para outros componentes. As interfaces
podem ser tanto definidas ao nvel de codificao (como em Java) quanto em interfaces binrias
usadas em run-time (como em OLE). Uma interface mostrada como uma linha partindo do
componente e com um crculo na outra extremidade. O nome colocado junto do crculo no final
da linha. Dependncias entre componentes podem ento apontar para a interface do componente
que est sendo usada.
9.9. Diagrama de Execuo
O diagrama de execuo mostra a arquitetura fsica do hardware e do software no sistema. Pode
mostrar os atuais computadores e perifricos, juntamente com as conexes que eles estabelecem
entre si e pode mostrar tambm os tipos de conexes entre esses computadores e perifricos.
Especifica-se tambm os componentes executveis e objetos que so alocados para mostrar quais
unidades de software so executados e em que destes computadores so executados.
O diagrama de execuo demonstra a arquitetura run-time de processadores, componentes fsicos
(devices), e de software que rodam no ambiente onde o sistema desenvolvido ser utilizado. a
ltima descrio fsica da topologia do sistema, descrevendo a estrutura de hardware e software
que executam em cada unidade.
O diagrama de execuo composto por componentes, que possuem a mesma simbologia dos
componentes do diagrama de componentes, nodes, que significam objetos fsicos que fazem parte
do sistema, podendo ser uma mquina cliente numa LAN, uma mquina servidora, uma
impressora, um roteador, etc., e conexes entre estes nodes e componentes que juntos compem
toda a arquitetura fsica do sistema.

30

31

10. Um processo para utilizar a UML

A UML contm notaes e regras que tornam possvel expressar modelos orientados a objetos.
Mas ela no prescreve como o trabalho tem que ser feito, ou seja, no possui um processo de
como o trabalho tem que ser desenvolvido. J que a UML foi desenvolvida para ser usada em
diversos mtodos de desenvolvimento.
Para usar a UML com sucesso necessrio adotar algum tipo de mtodo de desenvolvimento,
especialmente em sistema de grande porte onde a organizao de tarefas essencial. A utilizao
de um processo de desenvolvimento torna mais eficiente calcular o progresso do projeto, controlar
e melhorar o trabalho.
Um processo de desenvolvimento descreve "o que fazer", "como fazer", "quando fazer", e "porque
deve ser feito". Este tambm descreve um nmero de atividades que devem ser executadas em
uma certa ordem. Quando so definidas e relacionadas as atividades de um processo, um objetivo
especfico alcanado.
Em seu uso normal, a palavra "processo" significa uma relao de atividades que devem ser
executadas em uma certa ordem sem importar o objetivo, regras ou material a ser usado. No
processo de desenvolvimento da engenharia de software, necessrio saber o objetivo final do
processo, definir regras a serem seguidas e adotar um mtodo fixo de desenvolvimento.
Um mtodo (processo) tradicional de desenvolvimento orientado a objetos dividido em anlise de
requisitos, anlise, design (projeto), implementao, e testes. A anlise de requisitos captura as
necessidades bsicas funcionais e no-funcionais do sistema que deve ser desenvolvido. A anlise
modela o problema principal (classes, objetos) e cria um modelo ideal do sistema sem levar em
conta requisitos tcnicos do sistema. O design expande e adapta os modelos da anlise para um
ambiente tcnico, onde as solues tcnicas so trabalhadas em detalhes. A implementao
consiste em codificar em linguagem de programao e banco de dados os modelos criados. E as
atividades de testes devem testar o sistema em diferentes nveis, verificando se o mesmo
corresponde as expectativas do usurio.
Existe um processo desenvolvido pela Rational Inc., mesma empresa que desenvolveu a UML, que
monta duas vises do desenvolvimento de um sistema: viso gerencial e tcnica. A viso tcnica
utiliza as tradicionais atividades de anlise, design e implementao, enquanto a viso gerencial
utiliza as seguintes fases no desenvolvimento de cada gerao do sistema.

Incio: Define o escopo e objetivo do projeto;

Elaborao: Desenvolve o produto em detalhes atravs de uma srie de interaes. Isto

envolve mais anlise, design e programao;

Transio: Gera o sistema para o usurio final, incluindo as atividades de marketing,

suporte, documentao e treinamento.

Cada fase no ciclo executada em sries de interaes que podem sobrepor outras fases. Cada
interao consiste tipicamente em atividades tradicionais como anlise e design, mas em
diferentes propores dependendo da fase em que esteja a gerao do sistema em
desenvolvimento.
Ferramentas modernas devem dar suporte no apenas para linguagens de modelagem e
programao, mas devem suportar um mtodo de desenvolvimento de sistemas tambm. Isso
inclui conhecimento das fases em um processo, ajuda online, e aconselhamentos do que fazer em

32

cada fase do desenvolvimento, suporte a desenvolvimento interativo e fcil integrao com outras
ferramentas.

33

11. O Futuro da UML

Embora a UML defina uma linguagem precisa, ela no uma barreira para futuros
aperfeioamentos nos conceitos de modelagem. O desenvolvimento da UML foi baseado em
tcnicas antigas e marcantes da orientao a objetos, mas muitas outras influenciaro a linguagem
em suas prximas verses. Muitas tcnicas avanadas de modelagem podem ser definidas usando
UML como base, podendo ser estendida sem se fazer necessrio redefinir a sua estrutura interna.
A UML ser a base para muitas ferramentas de desenvolvimento, incluindo modelagem visual,
simulaes e ambientes de desenvolvimento. Em breve ferramentas de integrao e padres de
implementao baseados em UML estaro disponveis para qualquer um.
A UML integrou muitas idias adversas, e esta integrao vai acelerar o uso do desenvolvimento
de softwares orientados a objetos.

34

12. Um estudo de caso em UML

Diante do apresentado no decorrer do trabalho, aplicaremos aqui grande parte dos conceitos
abordados diante de uma aplicao da UML num problema fictcio que poder ser de grande ajuda
no melhor entendimento das potencialidades da linguagem de modelagem unificada.
O estudo de caso dar mais nfase na fases de anlise de requisitos, anlise e design, j que as
principais abstraes dos modelos do sistema se encontram nestas fases do desenvolvimento.
Desenvolveremos uma modelagem em UML para criarmos um sistema de manuteno e controle
de contas correntes e aplicaes financeiras de um banco fictcio.
Antes de dar incio primeira fase da modelagem, faremos algumas consideraes sobre o que o
sistema se prope a fazer e outras observaes que consideramos de suma importncia para o
bom entendimento do problema.

O sistema suportar um cadastro de clientes, onde cada cliente cadastrado poder ter
vrias contas correntes, vrios dependentes ligados a ele, e vrias contas de poupana.

Cada dependente poder possuir vrias contas de poupana, mas no podero ter uma
conta corrente prpria.

Entendemos poupana como uma conta que possui um valor, um prazo de aplicao a
uma taxa de juros (definida no vencimento da poupana).

Entendemos Aplicaes Pr-fixadas como uma aplicao de um valor, em um prazo prdeterminado a uma taxa de juros previamente definida.

Tanto a conta corrente quanto a poupana devero manter um histrico de todas as

movimentaes de crdito, dbito, transferncias e aplicaes de pr-fixados (pr-fixados
apenas para conta corrente).

Uma conta corrente poder ter vrias aplicaes pr-fixadas ligadas a ela.

12.1. Anlise de Requisitos

De acordo com nossa proposta o sistema implementar funes bsicas que sero
desempenhadas pela Administrao do banco e pelos seus clientes. As principais funes do
sistema so:

Cadastrar novo cliente

Excluir ou editar cliente

Cadastrar dependente

Excluir ou editar dependente

Abrir conta corrente

35

Fechar conta corrente

Abrir poupana

Fechar poupana

Movimentar conta corrente

Aplicar em pr-fixados

Consultar histrico de conta corrente ou poupana

Cadastrar Agncia

Excluir ou Editar Agncia

Tendo em mos esta relao de atividades, j podemos modelar o diagrama de use-case do

sistema.

36

12.2. Anlise
Na fase de anlise, tendo em mos o diagrama de use-case, podemos definir o diagrama de
classes do sistema. Este primeiro diagrama da fase de anlise dever ser totalmente
despreocupado de qualquer tipo de tcnica relacionada a implementao do sistema, ou seja,
mtodos e atributos de acesso a banco de dados, estrutura de mensagens entre objetos, etc. no
devero aparecer nesse primeiro diagrama, apenas os tipos de objetos bsicos do sistema.
Analisamos e percebemos que existiro 8 classes no sistema e que se relacionaro segundo o
diagrama de classes a seguir.

37

J temos em mos as funes primordiais do sistema (diagrama de use-cases) e o diagrama de

classes da anlise do domnio do problema, partiremos agora para traar como estas classes iro

38

interagir para realizar as funes do sistema. Lembramos que ainda nesta fase nenhum tipo de
tcnica de implementao deve ser considerada.
Para modelarmos como os objetos do sistema iro interagir entre si, utilizamos o diagrama de
sequncia ou o de colaborao. E modelaremos um diagrama para cada funo (use-case)
definida no diagrama de use-cases. Escolhemos o diagrama de sequncia para dar mais nfase a
ordem cronolgica das interaes entre os objetos. J se faz necessrio utilizar idias bsicas da
modelagem da interface do sistema como as janelas. Mas esses objetos de interface sero
totalmente detalhados na fase de design.

Nesta fase modela-se tambm o diagrama de estado das classes. Mas este se enquadra em
situaes onde o comportamento dos objetos importante para aplicao. Em casos de
modelagens de sistemas para equipamentos mecnicos.
12.3. Design
Nesta fase comearemos a implementar em nossos modelos os melhoramentos e tcnicas de
como realmente cada funco do sistema ser concebida. Sero modelos mais detalhados com
nfase nas solues para armazenamento dos dados, funes primordiais do sistema e interface
com o usurio.
A fase de design pode ser dividida em outras duas fases:

Design da arquitetura: Este o design de alto nvel onde os pacotes (subsistemas) so

definidos, incluindo as dependncias e mecanismos de comunicao entre eles.
Naturalmente, o objetivo criar uma arquitetura simples e clara, onde as dependncias
sejam poucas e que possam ser bidirecionais sempre que possvel.

Design detalhado: Esta parte detalha o contedo dos pacotes, ento todas classes sero
totalmente descritas para mostrar especificaes claras para o programador que ir gerar o
cdigo da classe. Modelos dinmicos do UML so usados para demonstrar como os
objetos se comportam em diferentes situaes.

Design da arquitetura

39

Uma arquitetura bem projetada a base para futuras expanses e modificaes no sistema. Os
pacotes podem ser responsveis por funes lgicas ou tcnicas do sistema. de vital importncia
separar a lgica da aplicao da lgica tcnica. Isso facilitar muito futuras mudanas no sistema.
Em nosso caso de estudo, identificamos 4 pacotes (subsistemas):

Pacote da Interface do Usurio: Estaro contidas as classes para a criao da interface do

usurio, para possibilitar que estes acessem e entrem com novos dados no sistema. Estas
classes so baseadas no pacote Java AWT, que o padro Java para criao de
interfaces. Este pacote coopera com o pacote de objetos do sistema, que contm as
classes onde os dados esto guardados. O pacote de interface chama operaes no
pacote de objetos do sistema para acessar e inserir novos dados.

Pacote de Objetos do Sistema: Este pacote inclui classes bsicas, ou seja, classes que
foram desenvolvidas exatamente para tornar o sistema em desenvolvimento funcional.
Estas classes so detalhadas no design, ento so includos operaes e mtodos em sua
estrutura e o suporte Persistncia adicionado. O pacote de objetos deve interagir com o
de banco de dados e todas as suas classes devem herdar da classe Persistente do pacote
de banco de dados

Pacote de Banco de Dados: Este pacote disponibiliza servios para as classes do pacote
de objetos fazendo com que os dados armazenados no sistema sejam gravados em disco.

Pacote de Utilidades: Este contm servios que so usados por todos os outros pacotes do
sistema. Atualmente a classe ObjId a nica no pacote, e usada para referenciar os
objetos persistentes em todo o sistema.

Design detalhado
O propsito do design detalhado descrever as novas classes tcnicas do sistema, como classes
de criao da interface, de banco de dados e para expandir e detalhar a descrio das classes de
objetos, que j foram definidas na fase de anlise.

40

Tudo isto feito com a criao de novos diagramas de classes, de estado, e dinmicos. Sero os
mesmos diagramas criados na fase de anlise, mas um nvel de detalhamento tcnico mais
elevado.
As descries de use-cases provenientes da fase de anlise so usados para verificar se estes
esto sendo suportados pelos diagramas gerados na fase de design, e diagramas de sequencia
so usados para ilustrar como cada use-case tecnicamente implementada no sistema.
Chegamos a um diagrama de classes mais evoludo com a incluso de persistncia.

41

42

Criamos os diagramas de sequencia para funes do sistema, descritas no diagrama de usecases, j possuindo os parmetros para cada mensagem entre os objetos.
O layout das janelas deve ser criado com alguma ferramenta visual de acordo com a preferncia
do desenvolvedor. Ferramentas visuais j geram o cdigo necessrio para a criao de janelas.
Algumas ferramentas j suportam a adio de controladores de eventos para eventos disparados
por usurios como cliques em botes. O ambiente gera um mtodo okbutton_Clicked que ser
chamado quando o boto "OK" for pressionado.
A aplicao resultante da interface de usurio uma janela principal com um menu de opes.
Cada opo escolhida do menu mostrar uma janela nova que juntas sero responsveis por
receber as informaes do usurio e executar a funo a qual se propem a fazer.
12.4. Implementao
A fase de construo ou implementao quando as classes so codificadas. Os requisitos
especificam que o sistema deve ser capaz de rodar em diversos tipo de processadores e sistemas
operacionais, ento a linguagem escolhida foi Java.
Pelo fato de em Java cada arquivo poder conter uma e somente uma classe, podemos facilmente
escrever um diagrama de componentes contendo um mapeamento das classes provenientes da
viso lgica.
Agora codificamos cada classe do pacote de objetos do sistema, a interface, o banco de dados e o
pacote de utilidades. A codificao deve ser baseada nos modelos desenvolvidos nas fases de
anlise de requisitos, anlise e design, mais precisamente nas especificaes de classes,
diagramas de classes, de estado, dinmicos, de use-cases e especificao.
Existiro algumas deficincias durante a fase de codificao. A necessidade da criao de novas
operaes e modificaes em operaes j existentes sero identificadas, significando que o
desenvolvedor ter que mudar seus modelos da fase de design. Isto ocorre em todos os projetos.
O que mais importante que sejam sincronizados a modelagem de design com a codificao,
desta forma os modelos podero ser usados como documentao final do sistema.
12.5. Testes
A aplicao dever ser testada. Deve-se verificar se o programa suporta toda a funcionalidade que
lhe foi especificada na fase de anlise de requisitos com o diagrama de use-cases. A aplicao
deve ser tambm testada da forma mais informal colocando-se o sistema nas mos dos usurios.

43

13. Concluso
O criao de uma linguagem para a comunidade de desenvolvedores em orientao a objetos era
uma necessidade antiga. A UML realmente incorporou muitos recursos com do a linguagem uma
extensibilidade muito grande.
Os organizao da modelagem em vises e a diviso dos diagramas especificando caractersticas
estticas e dinmicas do sistema tornou a UML fcil de ser utilizada e fez com que qualquer tipo de
comportamento possa ser visualizado em diagramas.
A modelagem visual orientada a objetos agora possui um padro, e esse padro extremamente
simples de ser escrito a mo, sendo robusto para especificar e descrever a grande maioria das
funes, relacionamentos e tcnicas de desenvolvimento orientado a objetos que hoje so
utilizados. Novas tcnicas iro surgir e a UML tambm estar preparada j que tudo estar
baseado nas idias elementares da orientao a objetos.
Sem dvida alguma a UML facilitar s grandes empresas de desenvolvimento de software uma
maior comunicao e aproveitamento dos modelos desenvolvidos pelos seus vrios analistas
envolvidos no processo de produo de software j que a linguagem que ser utilizada por todos
ser a mesma, acabando assim com qualquer problema de interpretao e mal-entendimento de
modelos criados por outros desenvolvedores. Os modelos criados hoje podero ser facilmente
analisados por futuras geraes de desenvolvedores acabando com a diversidade de tipos de
nomenclaturas de modelos, o grande empecilho do desenvolvimento de softwares orientados a
objetos.
Os fabricantes de ferramentas CASE agora suportaro a UML em seus softwares e a fase de
codificao ser cada vez mais substituda pela gerao de cdigo automtico desempenhada
pelas ferramentas CASE.

44