1.

Introduo
2. DesenvoIvimento de Softwares orientado a objetos
3. UML - A unificao dos mtodos para a criao de um novo padro
4. Uso da UML
5. Fases do DesenvoIvimento de um Sistema em UML
1. Anlise de Requisitos
2. Anlise
3. Design (Projeto)
4. Programao
5. Testes
6. A Notao da Linguagem de ModeIagem Unificada - UML
7. Vises
8. ModeIos de EIementos
1. Classes
2. Objetos
3. Estados
4. Pacotes
5. Componentes
6. Relacionamentos
7. Mecanismos Gerais
9. 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
10. Um processo para utiIizar a UML
11. O Futuro da UML
12. Um estudo de caso em UML - Sistema de ControIe de Contas Correntes,
Poupana e ApIicaes Pr-fixadas
1. Anlise de Requisitos
2. Anlise
3. Design
4. mplementao
5. Testes
13. ConcIuso




2
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 var 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 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.















3
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 SMULA. 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:
x A orientao a objetos uma tecnologia para a produo de modelos que
especifiquem o domnio do problema de um sistema.
x 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.
x 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.
x 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














4
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:
x 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.
x 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.
x OOSE/Objectory Os mtodos OOSE e o Objectory foram desenvolvidos baseados no
mesmo ponto de vista formado por var 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 use-cases, 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 var
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:
x A modelagem de sistemas (no apenas de software) usando os conceitos da
orientao a objetos;
x Estabelecer uma unio fazendo com que mtodos conceituais sejam tambm
executveis;
x Criar uma linguagem de modelagem usvel tanto pelo homem quanto pela mquina.
5
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:
x Sistemas de nformao: 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.
x 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.
x Sistemas Real-time ntegrados: 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.
x 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/RM.
x 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 em que disponibilizam interfaces
genricas de uso de outros softwares.
x 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.





6
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. AnIise 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. AnIise
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 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.
7
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 "use-cases".
O sistema ser testado pelo usurio final e verificar se os resultados mostrados esto
realmente de acordo com as intenes do usurio final.
PAROU AQUI~
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:
x 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.
x 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.
x 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.
x 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.







8
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. nfelizmente,
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:

x 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.
x 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 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, sequncia, colaborao e atividade.
x Viso de Componentes: uma descrio da implementao dos mdulos e suas
dependncias. principalmente executado por desenvolvedores, e consiste nos
componentes dos diagramas.
9
x 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, sequncia, colaborao e atividade, e
pelos diagramas de implementao, que so os diagramas de componente e
execuo.
x 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.

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. CIasses
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.
dentificar 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:
x 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.
x Existem sistemas externos ao modelado? Se existir, eles devero ser vistos como
classes pelo sistema para que possa interagir com outros externos.
10
x 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.
x 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
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.
11

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 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).
12
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. ReIacionamentos
Os relacionamentos ligam as classes/objetos entre si criando relaes lgicas entre estas
entidades. Os relacionamentos podem ser dos seguintes tipos:
x 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.
x 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.
x 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:
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.
13
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 QuaIificada
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
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.

14
Associao ExcIusiva
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 linha de associao entre as duas classes.
Associao de CIasse
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.

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.
15
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.
x 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.

No exemplo acima uma pessoa pode ser membro de um time ou vrios times e
em determinado momento.
x 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.
16

8.6.2. GeneraIizaes
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.
GeneraIizao NormaI
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.
GeneraIizao 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:
x 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.
17

x Generalizaes Completa e ncompleta: 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 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.

18
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.
x 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.
x 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.





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.
19
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 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.
20

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 CIasses
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.
21

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 de estado no so escritos para todas as classes de um sistema, mas apenas
22
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.
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
23
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 CoIaborao
Um diagrama de colaborao mostra de maneira semelhante ao diagrama de sequncia, 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.
24

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:
x Para capturar os trabalhos que sero executados quando uma operao disparada
(aes). Este o uso mais comum para o diagrama de atividade.
x Para capturar o trabalho interno em um objeto.
x Para mostrar como um grupo de aes relacionadas podem ser executadas, e como
elas vo afetar os objetos em torno delas.
x Para mostrar como uma instncia pode ser executada em termos de aes e objetos.
x 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.
25

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.
26

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.

27
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 s 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 nc., 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.
x ncio: Define o escopo e objetivo do projeto;
x Elaborao: Desenvolve o produto em detalhes atravs de uma srie de interaes.
sto envolve mais anlise, design e programao;
x 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. sso
inclui conhecimento das fases em um processo, ajuda online, e aconselhamentos do que fazer
em cada fase do desenvolvimento, suporte a desenvolvimento interativo e fcil integrao com
outras ferramentas.

28
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.

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.
x 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.
x Cada dependente poder possuir vrias contas de poupana, mas no podero ter
uma conta corrente prpria.
x Entendemos poupana como uma conta que possui um valor, um prazo de aplicao a
uma taxa de juros (definida no vencimento da poupana).
x Entendemos Aplicaes Pr-fixadas como uma aplicao de um valor, em um prazo
pr-determinado a uma taxa de juros previamente definida.
x 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).
x Uma conta corrente poder ter vrias aplicaes pr-fixadas ligadas a ela.
29
12.1. AnIise 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:
x Cadastrar novo cliente
x Excluir ou editar cliente
x Cadastrar dependente
x Excluir ou editar dependente
x Abrir conta corrente
x Fechar conta corrente
x Abrir poupana
x Fechar poupana
x Movimentar conta corrente
x Aplicar em pr-fixados
x Consultar histrico de conta corrente ou poupana
x Cadastrar Agncia
x Excluir ou Editar Agncia
Tendo em mos esta relao de atividades, j podemos modelar o diagrama de use-case do
sistema.
30

12.2. AnIise
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.
31

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 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)
32
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 funo 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:
x 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.
x 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
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. sso facilitar muito futuras
mudanas no sistema.
Em nosso caso de estudo, identificamos 4 pacotes (subsistemas):
33

x Pacote da nterface 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.
x 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
x 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.
x Pacote de Utilidades: Este contm servios que so usados por todos os outros
pacotes do sistema. Atualmente a classe Objd a nica no pacote, e usada para
referenciar os objetos persistentes em todo o sistema.
Design detaIhado
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.
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
sequncia so usados para ilustrar como cada use-case tecnicamente implementada no
sistema.
34
Chegamos a um diagrama de classes mais evoludo com a incluso de persistncia.

Criamos os diagramas de sequncia para funes do sistema, descritas no diagrama de use-
cases, j possuindo os parmetros para cada mensagem entre os objetos.
35
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. ImpIementao
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. sto 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.
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
36
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.
37