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
2
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
3
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 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. DesenvoIvimento 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.
4
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 var Jacobson. O mtodo OOSE a viso de
5
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.
6
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 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.
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 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.
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.
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.
7
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 DesenvoIvimento 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)
8
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.
9
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.
6. A Notao da Linguagem de ModeIagem 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. 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:
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 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.
11
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.
8. ModeIos de EIementos
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.
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:
12
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
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.
13
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.
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.
14
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).
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
ou um componente do sistema, e ser mostrado no diagrama de componentes
que os utiliza.
15
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:
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).
16
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.
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.
17
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 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.
Associao Ternria
18