UML

A Unified Modeling Language (UML) uma linguagem de modelagem no

proprietria de terceira gerao. A UML no uma metodologia de desenvolvimento, o que
significa que ela no diz para voc o que fazer primeiro e em seguida ou como projetar seu
sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicao entre objetos.
Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus
trabalhos em diagramas padronizados. Junto com uma notao grfica, a UML tambm
especifica significados, isto , semntica. uma notao independente de processos, embora
o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a
UML.
importante distinguir entre um modelo UML e um diagrama
1
(ou conjunto de
diagramas) de UML. O ltimo uma representao grfica da informao do primeiro, mas
o primeiro pode existir independentemente. O XMI (XML Metadata Interchange) na sua
verso corrente disponibiliza troca de modelos mas no de diagramas.
Os objetivos da UML so: especificao, documentao, estruturao para sub-
visualizao e maior visualizao lgica do desenvolvimento completo de um sistema de
informao. A UML um modo de padronizar as formas de modelagem.
As propriedades estticas dos objetos so representadas pelos atributos e possuem as
seguintes caractersticas:
Tipo: determina o classificador das instncias dos valores, que pode ser uma
classe, um tipo de dado primitivo ou uma interface;
Multiplicidade: determina quantas instncias de valores um determinado
produto pode ter;
Valor inicial: determina o valor do atributo quando o objeto inicializado;
Escopo: determina se cada valor esta relacionado a uma instncia da classe
ou se esta relacionada diretamente classe.
Mutabilidade: determina se o valor do atributo pode ser alterado aps a
criao do objeto.
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:

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.




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.

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.

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.

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.

A Notao da Linguagem de Modelagem Unificada
UML

Tendo em mente as cinco fases do desenvolvimento de softwares, as fases de anlise
de requisitos, anlise e design utilizam-se em seu desenvolvimento cinco tipos de vises, nove
tipos de diagramas e vrios modelos de elementos que sero utilizados na criao dos
diagramas e mecanismos gerais que todos em conjunto especificam e exemplificam a
definio do sistema, tanto a definio no que diz respeito funcionalidade esttica e
dinmica do desenvolvimento de um sistema.
Antes de abordarmos cada um destes componentes separadamente, definiremos as
partes que compem a UML:
Vises: as Vises mostram diferentes aspectos do sistema que est sendo
modelado. A viso no um grfico, mas uma abstrao consistindo em uma
srie de diagramas. Definindo um nmero de vises, cada uma mostrar
aspectos particulares do sistema, dando enfoque a ngulos e nveis de
abstraes diferentes e uma figura completa do sistema poder ser
construda. As vises tambm podem servir de ligao entre a linguagem de
modelagem e o mtodo/processo de desenvolvimento escolhido.
Modelos de elementos: os conceitos usados nos diagramas so modelos de
elementos que representam definies comuns da orientao a objetos como
as classes, objetos, mensagem, relacionamentos entre classes incluindo
associaes, dependncias e heranas.
Mecanismos gerais: os mecanismos gerais provm comentrios
suplementares, informaes, ou semntica sobre os elementos que compem
os modelos; eles provm tambm mecanismos de extenso para adaptar ou
estender a UML para um mtodo/processo, organizao ou usurio especfico.
Diagramas: os diagramas so os grficos que descrevem o contedo em uma
viso. UML possui nove tipo de diagramas que so usados em combinao
para prover todas as vises do sistema.

Vises

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.
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, sequncia, colaborao e atividade.
Viso de componentes: uma descrio da implementao dos mdulos e suas
dependncias. principalmente executado por desenvolvedores, e consiste
nos componentes dos diagramas.
Viso de concorrncia: trata a diviso do sistema em processos e
processadores. Este aspecto, que uma propriedade no funcional do
sistema, permite uma melhor utilizao do ambiente onde o sistema se
encontrar, se o mesmo possui execues paralelas, e se existe dentro do
sistema um gerenciamento de eventos assncronos. Uma vez dividido o
sistema em linhas de execuo de processos concorrentes (threads), esta viso
de concorrncia dever mostrar como se d a comunicao e a concorrncia
destas threads. A viso de concorrncia suportada pelos diagramas
dinmicos, que so os diagramas de estado, sequncia, 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.

Modelos de Elementos

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.

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.
Realizao: relacionamento semntico entre classificadores em que um
classificador especifica um contrato que outro classificador ir implementar.
Ou melhor, a realizao um relacionamento entre os itens que implementa
o comportamento especificado por outro. Um exemplo disso seria as classes
abstratas e as interfaces que definem que o objeto filho dever realizar
algum mtodo, propriedade no momento da herana.

Tipos de Diagramas

Diagramas estruturais: classe, objeto, pacote, componente, estrutura
composta, implantao e perfil;
Diagramas comportamentais: caso de uso, atividades e mquina de estados;
Diagramas comportamentais de interao: sequncia, comunicao, interao
geral e tempo.

Blocos de Construo

1. Itens e elementos
o Estruturais: classes, interfaces, colaboraes, casos de uso, classes
ativas, componentes e ns;
o Comportamentais: iteraes e mquina de estados;
o De agrupamento: blocos do modelo que podem ser decomposto;
o De anotaes: anotaes no diagrama, representadas pela nota.
2. Relacionamentos: associao, dependncia, generalizao e realizao.
3. Diagramas: classe, objeto, pacotes, estrutura composta, componentes,
implantao, caso de uso, estado, atividades, perfil, colaborao, sequncia,
comunicao e tempo.

Mecanismos comuns da UML

Para tornar a construo do sistema mais simples e harmoniosa.
a) Especificaes: repertrio semntico para determinar os detalhes do sistema
(p.ex. atributos e operaes de classe);
b) Adornos: variedades especficas de smbolos bsicos;
c) Divises comuns: dicotomias comuns da UML, como entre
interface/implementao, tipo/papel e classes/objetos (e similares para outros
blocos, como para casos de uso/instncias de casos de uso);
d) Mecanismos de extenso: permitem ampliar a UML de maneira controlada.
Podem ser de 3 tipos:
Esteretipos: permite a criao de novos tipos de blocos de
construo derivados dos j existentes;
Valores atribudos: estendem as propriedades dos blocos de
informao, criando novas informaes;
Restries: ampliam a semntica dos blocos de construo da UML,
permitindo alterar as regras existentes ou criar novas regras.
A UML pode ser estendida atravs de extenses de peso leve ou de peso pesado. As
primeiras estendem as metaclasses da UML ou restringem ainda mais os elementos
existentes. As segundas permitem alteraes mais profundas, como novas metaentidades ou
alteraes profundas nas metaentidades existentes.

Diagrama de Classe

O diagrama de classes demonstra a estrutura esttica das classes de um sistema onde
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 classe pode
participar de vrios diagramas de classes.

Associao



As associaes representam as relaes entre as ocorrncias das classes. um tipo de
relacionamento estrutural e esttico entre as classes. As associaes em um diagrama de
classe definem os tipos de ligaes que os objetos participam. O termo associao binria
se refere a uma associao entre duas classes.

Agregao

A associao de agregao sempre para indicar que um objeto colabora com outro
objeto, mais a existncia desse objeto no obrigatria. Podemos dizer tambm que uma
associao em que um objeto parte de outro, de tal forma que a parte pode existir sem o
todo. Em mais baixo nvel, uma agregao consiste de um objeto contendo referncias para
outros objetos, de tal forma que o primeiro seja o Todo, e que os objetos referenciados sejam
as partes do todo. Tambm podemos dizer que uma relao do tipo todo/parte ou
possui um esse ltimo mais utilizado na qual uma classe representa uma coisa grande
que composta de coisas menores (classes agregadas).



Composio

A associao de composio um tipo de associao de agregao, mais a diferena
entre elas que a composio faz parte do todo e depende do todo. Em outras palavras, os
objetos so inseparveis, quando um objeto Pai destrudo o objeto filho tambm , pois ele
faz parte do todo e componente todo.


Quando se tem uma classe que depende de outra classe para ser utilizada e quando se
destri essa classe a outra tambm deve ser apagada ai temos um relacionamento de
composio.

Relacionamentos

1. Entre classes:
o Dependncia;
o Generalizao;
o Associao.
2. Entre classes e interfaces:
o Dependncia;
o Associao;
o Realizao.
3. Entre interfaces:
o Generalizao.

Generalizao

um relacionamento onde temos uma classe ancestral (supertipo) e outras classes
herdadas (subtipos), o subtipo deve incluir todos os elementos (atributos e operaes) do
supertipo.



Realizao

Relacionamento semntico entre classificadores em que um classificador especifica
um contrato que outro classificador garante executar.
uma relao entre uma interface e a classe que a implementa, i.e., que prov o
servio definido pela interface.
A realizao um relacionamento entre os itens que implementa o comportamento
especificado por outro. Um exemplo disso seria as classes abstratas e as interfaces que
definem que o objeto filho dever realizar algum mtodo, propriedade no momento da
herana.



Interface

A interface define apenas a assinatura dos mtodos da classe sem apresentar sua
implementao. Normalmente, nas linguagens de programao orientadas a objetos, as
interfaces no apresentam atributos. A interface implementa a programao por contrato. A
figura a seguir apresenta duas representaes de interface e o seu relacionamento com uma
classe. No segundo exemplo note o uso do esteretipo para evidenciar a interface.



Uma interface fornecida descreve um servio implementado por uma classe. O
conjunto de interfaces implementadas por uma classe so suas interfaces fornecidas e
representam o conjunto de servios que a classe ao implementar uma interface suporta o
conjunto de caractersticas possudas por esta e obedece s suas restries.
Uma interface requerida, descrevem os servios que outras classes devem fornecer a
uma determinada classe, que no precisa ter conhecimento de quais classes iro implementar
estes servios.



Dependncia

Esse tipo de relacionamento indica que a mudana em um elemento pode causar
mudanas em outros elementos. Nesse caso um elemento depende do outro, sendo que se um
elemento mudar o outro poder ser afetado.



No exemplo acima, qualquer alterao na classe Formulrio poder afetar a classe
GUI. A notao usada para representar a dependncia, um segmento de reta tracejado com
uma seta aberta apontando para a classe dependida.

Esteretipos

Os esteretipos so uma extenso do vocabulrio da UML, que permite a criao de
novos tipos de blocos de construo derivados dos j existentes, mas que so especficos ao
seu problema. Os esteretipos so representados por aspas francesas ( <<nome do
esteretipo>> ). Os esteretipos so normalmente predefinidos na prpria linguagem UML,
por outro lado, a equipe de desenvolvimento pode definir os seus prprios esteretipos.
Alguns exemplos:
<<bounday>> ou classe de fronteira: usada para modelar a interao entre o
ambiente do sistema e seus trabalhos internos;
<<control>> ou classe de controle: usada para modelar um comportamento
de controle especfico de um ou alguns casos de uso;
<<entity>> ou classe de entidade: usada para modelar as informaes e o
comportamento associado que devem ser armazenados.

Enumerao

um recurso usado em vrias linguagens de programao. So listas (literais) que
podem ser armazenados como valores ou passados como parmetros. Para representar usa-se
o esteretipo: <<enumerated>> ou <<enumeration>>.




Diagrama de Atividades

O diagrama de atividades um diagrama UML utilizado para modelar o aspecto
comportamental de processos. um dos diagramas que mais sofreu mudanas em ser meta-
modelo, desde o seu surgimento. Neste diagrama, uma atividade modelada como uma
sequncia estruturada de aes, controladas potencialmente por ns de deciso e
sincronismo. Em seu aspecto mais simples, um diagrama de atividades pode ser confundido
com um fluxograma. Entretanto, ao contrrio de fluxogramas, os diagramas de atividades
UML suportam diversos outros recursos, tais como as parties e os ns do tipo fork e merge,
alm da definio de regies de interrupo, que permitem uma modelagem bem mais rica do
que simplesmente um fluxograma.

Atividades

Booch (2005) define uma atividade como: comportamento expresso como um
conjunto de aes conectadas por fluxos de controle de dados. Percebe-se, nesta definio
que a atividade algo que est em andamento, ou conforme Fowler (2000) define, um
estado de estar fazendo algo, assim as atividades so no atmicas e resultam ou so
resultantes de outras aes que provocaro mudanas de estado em um sistema.

Estados de Ao

O estado de ao, segundo Melo (2000) um tipo simplificado de estado da mquina
de estado, eles no devem ter transies internas. Guedes (2008) refora a tese de que os
estados de ao, ao contrrio das atividades, so atmicos, ele descreve: Um estado de ao
representa a realizao de uma ao dentro de um fluxo de controle, atmico, ou seja, no
podem ser decompostos em sub-estados. Um estado de ao no possui aes internas e sua
execuo considerada to rpida que no pode ser interrompida. Uma atividade costuma
possuir diversos Estados de Ao.
Assim, os estados de ao, representam os estados que so alterados a partir das
transies (de um estado para o outro), gerados por condies de guarda e aes (vistos mais
adiante nesse artigo).
Tanto os estados de ao e/ou atividades so representados por um retngulo de
pontas arredondadas com a descrio da ao em seu interior.

N de Atividade

O n de atividade outro conceito discutido quando estudamos o diagrama de
atividades. Ns de atividades so vrias aes agrupadas dentro de uma nica atividade, por
outro lado, podemos conceber uma ao, como um n de atividade que no pode ser
descomposto.

Conector de Incio

Trata-se da representao de uma atividade abstrata que tem por objetivo apenas
determinar o incio de um processo. representado por um crculo preenchido e a partir
deste iniciado um primeiro estado.

Conector de Fim

De forma anloga ao conector de incio, o conector de fim (ou de finalizao), trata-
se da representao de uma atividade abstrata que tem por objetivo apenas determinar o fim
de um processo. representado por dois crculos concntricos, um preenchido e outro no.


Fluxos de Controle ou Transies

Com o propsito de associar uma atividade ou estado de ao a outro, informando
que a atividade anterior foi completada a partir da execuo de suas aes, so usados os
fluxos (ou transies de estado). Esses so representados por setas.

Condio de Guarda e Ao

A condio de guarda trata-se de uma expresso lgica (pode ser verdadeira ou no),
capaz de alterar o estado do objeto ou de uma atividade. A situao de guarda normalmente
est associada aps um branch (ou deciso do diagrama de atividades) e um dos fatores
para o disparo de uma transio. Uma transio somente ser disparada se existir um evento
associado a ela e a situao de guarda permitir. No diagrama de atividades a guarda
representada entre colchetes ([ guarda ]).
A ao, no diagrama de Atividades, trata-se de uma operao ou algo instantneo
que no pode ser interrompido. Um objeto ao mudar de um estado a outro pode realizar
diversas aes. No diagrama de atividades representada por uma barra (/ ao).

Branch (Desvio)

O Branch (deciso ou desvio) mostra um desvio no fluxo da atividade com vrias
opes de sadas guardadas (condies de guarda). Nessa situao, apenas uma opo de
sada pode ser tomada. Observa-se que diagrama de atividades modela lgica de um
processo de Workflow e processos especficos envolvendo lgica, ele traz em suas anotaes
detalhes dos fluxogramas, mas acrescenta conceitos de concorrncia e deciso.

Merge (Intercalao)

O Merge usado para finalizar o processo de deciso, ou seja, marca o final de um
comportamento condicional iniciado por um branch.

Fork (Bifurcao) e Join (Juno)

Trata-se de uma opo para representar o processamento em paralelo, assim tem-se
uma opo de entrada e vrias opes de sada. Quando a opo de entrada acionada (ou
disparada) as opes de sada so iniciadas (acionadas) em paralelo. A juno ou unio,
marca a finalizao de um fork.
Transies sequenciais com ramificaes simples so os caminhos mais comuns a
serem encontrados em diagramas de atividades. Entretanto principalmente quando estiver
fazendo a modelagem de fluxo de trabalho de processos de negcio voc encontrar fluxos
concorrentes. Na UML, a barra de sincronizao empregada para especificar a bifurcao e
a unio desses fluxos paralelos de controle.

Swinlanes (Raias)

As raias de natao so usadas para identificar, no diagrama de atividades, entidades
(e eventualmente as classes) responsveis por cada atividade (ou grupo de atividades).

Diagrama de Caso de Uso

O diagrama de caso de uso um diagrama da UML cujo objetivo representar um
requisito do sistema que ser automatizado. Considere como requisito uma necessidade do
sistema.
O diagrama de casos de uso corresponde a uma viso externa do sistema e representa
graficamente os atores, os casos de uso, e os relacionamentos entre estes elementos. Ele tem
como objetivo ilustrar em um nvel alto de abstrao quais elementos externos interagem
com que funcionalidades do sistema, ou seja, a finalidade de um diagrama de caso de uso
apresentar um tipo de diagrama de contexto que apresenta os elementos externos de um
sistema e as maneiras segundo as quais eles as utilizam.
A notao utilizada para ilustrar atores em um diagrama de caso de uso a figura de
um boneco, com o nome do ator definido abaixo dessa figura. Vale ressaltar que um ator
nem sempre um ser humano. qualquer elemento externo que interage com o sistema
(pessoas, organizaes, outros sistemas, equipamentos). Para representar casos de uso,
utilizamos uma elipse, com o nome do caso de uso dentro da elipse, ou abaixo dela.
Um relacionamento de comunicao representado por um segmento de reta ligando
ator e caso de uso, sendo que um ator pode estar relacionado vrios casos de uso em um
mesmo diagrama.

Objetivo

Especificar o contexto de um sistema;
Capturar os requisitos funcionais de um sistema;
Validar a arquitetura de um sistema;
Dirigir a implementao e gerar casos de teste.

Na UML h 3 tipos de relacionamentos entre Casos de Uso, so eles:

Incluso: possibilita a subdiviso de casos de uso, bem como evita a descrio
de uma mesma sequncia de interaes. Permite agrupar funcionalidades
comuns em um ponto nico de utilizao;
Generalizao: pode existir entre dois casos de uso ou entre dois atores.
Permite que tanto um caso de uso como um ator herdem caractersticas de
outro mais genrico. O caso de uso ou ator herdeiro pode especializar o
comportamento do caso de uso ou ator base. Utiliza o mesmo smbolo da
herana de classes. UML tambm permite utilizar o conceito de entidade
abstrata ao Caso de Uso descrito em itlico;
Extenso: no confundir com generalizao. Utilizado para expressar
diferentes sequncias de interaes entre casos de uso. Caminhos alternativos
ou excees. Cada uma das diferentes sequncias representa um
comportamento opcional, que s ocorre sob certas condies ou cuja
realizao depende da escolha do ator.

Em relao incluso e extenso

A seta saindo de um caso de uso apontando para o caso de uso base indica uma
relao de extenso (opcionalidade na execuo do caso extendido).
J a seta saindo do caso de uso base e apontando para um caso de uso indica uma
relao de incluso (obrigatoriedade na execuo do caso de uso includo).
Normalmente incluem-se os esteretipos <<include>>, <<extends>> nestas setas.

Tipos de Casos de Uso

Caso de uso caixa preta: detalhes internos sobre como o sistema responde s
aes de um ator esto ausentes ou descritas muito resumidamente;
Caso de uso caixa branca: detalhes internos sobre como o sistema responde s
aes de um ator esto presentes e descritas detalhadamente.




Formatos dos Casos de Uso

Breve/Resumido: resumo conciso de um pargrafo que, usualmente, trata do
cenrio principal;
Casual/Informal: vrios pargrafos informais so definidos para abordar
vrios cenrios;
Completo: o mais elaborado. Todos os passos e variaes so descritas
detalhadamente. Tambm incluem outras sees, como pr-condies e ps-
condies.

Tipos de Itens

Estruturais: tambm chamados de classificadores. So os substantivos
utilizados em modelos UML. So as partes mais estticas do modelo;
Comportamentais: so as partes dinmicas dos modelos de UML. So os
verbos representando comportamentos no tempo e no espao;
Agrupamento: so as partes organizacionais do modelo UML;
Anotacionais: so as partes explicativas dos modelos. So comentrios.

Diagrama de Sequncia

O diagrama de sequncia uma das ferramentas UML usadas para representar
interaes entre objetos de um cenrio, realizadas atravs de operaes ou mtodos
(procedimentos ou funes). Este diagrama construdo a partir do Diagrama de Casos de
Uso. Primeiro, se define qual o papel do sistema (Use Cases), depois, definido como o
software realizar seu papel (Sequncia de operaes).
O diagrama de sequncia d nfase a ordenao temporal em que as mensagens so
trocadas entre os objetos de um sistema. Entende-se por mensagens os servios solicitados de
um objeto a outro, e as respostas desenvolvidas para as solicitaes.

Tipos de Mensagens

Sncrona: o emissor fica bloqueado at o receptor receber e tratar a
mensagem;
Assncrona: emissor continuar a emitir mensagens, no h dependncias.





Tipos de Interao



Mensagem de Retorno

Este tipo de mensagem identifica a resposta a uma mensagem para o objeto que a
chamou. Uma mensagem de retorno pode retornar informaes especficas do mtodo
chamado ou apenas um valor indicado se o mtodo for executado com sucesso ou no.




Auto-chamada ou Auto-delegao

So mensagens que partem da linha de vida do objeto e atinge a linha de vida do
prprio objeto.



Controle Estruturado

Uma sequncia de mensagens boa para mostrar uma nica sequncia linear, mas
frequentemente precisamos mostrar condicionais e loops. s vezes, preciso mostrar a
execuo concorrente de vrias sequncias. O tipo de alto nvel pode ser apresentado com
operadores de controle estruturado nos diagramas de sequncia.
Tag OPT: o corpo do operador de controle executado se uma condio de
proteo for verdadeira na entrada do operador. A condio de proteo
uma expresso booleana que pode aparecer entre colchetes na parte superior
de qualquer linha de vida no corpo, e pode fazer referncia a atributos desse
objeto;
Tag ALT: o corpo do operador de controle dividido em vrias sub-regies,
por linhas horizontais tracejadas. Cada sub-regio representa um ramo de
uma condicional. Cada sub-regio tem uma condio de proteo. Se a
condio de proteo de uma regio for verdadeira, a sub-regio ser
executada. Entretanto, no mximo uma sub-regio pode ser executada; se
mais de uma condio de proteo for verdadeira, a escolha da sub-regio
no ser determinstica, podendo varias de execuo para execuo. Se
nenhuma condio de proteo for verdadeira, o controle continua passando
pelo operador de controle. Uma sub-regio pode ter uma condio de
proteo especial [else]; essa sub-regio ser executada, se nenhuma das
outras condies de proteo for verdadeira;
Tag PAR: o corpo do operador de controle dividido em vrias sub-regies
por linhas horizontais tracejadas. Cada sub-regio representa uma
computao paralela (concorrente);
Tag LOOP: uma condio de proteo aparece na parte superior de uma linha
de vida no corpo. O corpo do loop executado repetidamente enquanto a
condio de proteo verdadeira, antes de cada iterao. Quando a
condio de proteo falsa na parte superior do corpo, o controle sai do
operador de controle;
Tag BREAK: este operador de interao indica uma quebra na execuo
do processo. usado principalmente para modelar o tratamento de
execees.

Fragmentos de Interao

Os fragmentos de interao so noes abstratas de unidades de interao geral. Um
fragmento de interao uma parte de uma interao, no entanto, cada fragmento de
interao considerado uma interao independente.
Uma das principais vantagens do uso de fragmentos de interao caracteriza-se pela
possibilidade de se poder referenci-los por meio do operador Ref, que abreviatura de
Referred (referido) e significa que se deve procurar por um diagrama cujo nome o mesmo
do nome apresentado aps o operador Ref, ou seja, o fragmento faz referncia a outro
diagrama no detalhado no diagrama em questo e que deve ser inserido neste, a isto se
chama ocorrncia de interao e esta inovao permite que se montem diagramas mais
complexos que fazem referncia a outros diagramas como se fossem sub-rotinas, detalhadas
em separado.

Portes (Gates)

Um porto uma interface entre fragmentos, um ponto de conexo para relacionar
uma mensagem fora de um fragmento de interao com uma mensagem dentro do fragmento
de interao. Portes so representados simplesmente pelo encontro da seta da mensagem
no retngulo do fragmento de interao, ou, em algumas ferramentas CASE, por pequenos
quadrados posicionados na linha vertical do retngulo do fragmento, na altura em que a
mensagem dever atingir a linha de vida do objeto a que ele se refere. O propsito de um
porto simplesmente estabelecer que esta enviando e quem est recebendo uma mensagem,
quando esta mensagem no est contida em um nico fragmento de interao.

Diagrama de Objetos

O diagrama de objetos uma variao do diagrama de classes. A diferena que
neste diagrama voc pode colocar os nomes reais aos seus objetos. O diagrama de objetos no
to importante quanto o de classes, mas ele vai ajudar a exemplificar um diagrama de
classes muito complexo.
Por exemplo, uma pessoa fsica que se chama Marcelo, voc pode definir um objeto
Marcelo e representa ele aqui. Tecnicamente podemos dizer que o diagrama de objetos
representa uma instncia da classe.
Os diagramas de objetos tm seu nome sublinhado e todos os seus relacionamentos
so mostrados. Seu nome vm separado da classe que ele representa por : (dois pontos).
A representao de um objeto um retngulo composto por dois compartimentos,
veja figura abaixo. No primeiro compartimento exibido o nome do objeto, e no segundo
compartimento os atributos e seus valores so exibidos.



O primeiro compartimento denotado pelo nome do objeto + o tipo do objeto.
Exemplo: o objeto d1 do tipo Department, ou seja, o objeto d1 pertence a classe
Department. importante ressaltar que a identificao do objeto deve ser sempre
sublinhada.
No diagrama de objetos temos tambm os objetos annimos. Nesse caso, o nome
objeto no exibido. Como podemos ver na figura acima, ContactInformation um exemplo
de objeto annimo.
O segundo compartimento opcional. Sua notao o nome do atributo seguido do
valor do atributo. Os diagramas de objetos tambm representam o vinculo entre os objetos.
Os vnculos so representados por um segmento de reta ligando dois objetos. Esse
diagrama, ao contrrio do diagrama de classes, raramente utilizado.

Diagrama de Pacotes

Agrupa as classes em unidades de nvel mais alto. Esses elementos podem ser classes,
diagramas ou at mesmo outros pacotes. O diagrama de pacotes, ou diagrama de mdulos,
definido pela UML descreve os pacotes ou pedaos do sistema divididos em agrupamentos
lgicos mostrando as dependncias entre estes, ou seja, pacotes podem depender de outros
pacotes.

1. Um pacote pode ter o nome dentro ou na tab.



2. Os pacotes se relacionam atravs de suas dependncias.

Na realidade, no existe propriamente diagramas de pacotes em UML. Pacotes e
relaes entre pacotes aparecem em outros diagramas.
Pacotes de caso de uso;
Pacotes de classes;
Pacotes de componentes;
Pacotes de ns.
Uma vez que representa um agrupamento, um pacote , em geral, dono de diversos
elementos.
Classes;
Interfaces;
Componentes;
Ns;
Colaboraes;
Casos de uso.

Dependncia de Pacotes

Dependncia simples: uma alterao do pacote de destino afeta o pacote de
origem (dependente);
Dependncia <<acess>>: o pacote de origem (dependente) acede elementos
exportados pelo pacote destino;
Dependncia <<import>>: o contedo pblico do pacote de destino
adicionado ao pacote de origem.

Diagrama de Estados

Podemos ver o diagrama de estados como um complemento para o diagrama de
classes. Neste diagrama podemos mostrar qual o estado em que o nosso objeto esta naquele
momento. O diagrama de estado deve ser construdo para os objetos que tem seus estados
definidos e onde o comportamento do objeto muda por causa de um determinado estado.
O diagrama de estados visa o estudo do comportamento do objeto. Ele descreve as
etapas pelas quais um objeto passa durante sua existncia. Objetos cujas mudanas de
estado sejam complexas e difceis de entender podem ficar mais claros com o uso deste tipo
de diagrama.
Como os diagramas na UML so complementares, o diagrama de classe deve ter uma
propriedade para a informao do estado do objeto criado e o diagrama de caso de uso deve
prever a alterao do estado deste objeto nas vrias etapas do seu ciclo de vida.
O diagrama de estados pode ser usado para descrever atores, subsistemas, operaes
e objetos, mas comumente utilizado para objetos.

Componentes

Ponto inicial onde o objeto nasce;
Ponto final onde o objeto deixa de existir;
Transio relacionamento entre dois estados. Indica que um objeto no
primeiro estado realizar certas aes (processos) e entrar no segundo estado
quando um evento ocorrer ou uma condio (guarda) for satisfeita.
o Evento: ocorrncia de um estmulo que aciona uma mudana de
estado;
o Guarda: uma condio lgica, a transio ocorre quando a guarda
for verdadeira;
o Ao: processo associado transio, a mudana de estado ocorre
quando a ao executada.
Estado possui um nome a vrias partes internas, que so opcionais. A
atividade um processo associado ao estado.

Estados

So as situaes de um objeto nas quais ele satisfaz alguma condio, aguarda um
evento ou realiza alguma atividade.
Um diagrama de estados pode ser baseado em uma classe, mas podem existir classes
sem estados a serem modeladas. Portanto um sistema pode ter vrios diagramas de estados e
uma classe pode ter mais de um diagrama de estado associado.
Outra forma de desenhar um estado separ-lo em dois compartimentos: um para
um nome e outro para transies internas ao estado.



Esta diviso opcional e adotada em situaes onde muitos mtodos sejam
chamados nas diferentes etapas da transio de estados. Possui os seguintes elementos:
Compartimento de Nome: local onde conter o nome do estado;
Compartimento de Transies Internas: lista as aes ou atividades
executadas enquanto o objeto estiver no estado em foco;
As palavras reservadas que aparecem antes das aes na rea de transies internas
identificam o evento que disparado:
Entry identifica uma ao que executada na entrada do estado;
Exit identifica uma ao que executada na sada do estado;
Do identifica uma atividade executada continuamente enquanto o objeto
estiver no estado;
Include uma chamada a uma submquina;
On evento a ao ser executada ao ocorrer este evento, sem que o objeto
saia deste estado. Tambm chamado de transio externa.

Subestados

Um estado simples aquele que no possui subestrutura. Um estado que possui
subestados (estados aninhados) denominado estado composto. Os subestados podem ser
aninhados em qualquer nvel. Uma mquina de estados aninhados deve ter no mximo um
estado inicial e um estado final. Os subestados so usados para simplificar mquinas
complexas de estados simples mostrando que alguns estados so possveis apenas dentro de
um determinado contexto (o estado confinado).

Diagrama de Implantao

Um diagrama que mostra a configurao dos ns de processamento em tempo de
execuo e os componentes, processos e objetos que neles vivem.
Um dos diagramas que acredito ser um dos mais importantes tambm um dos
menos vistos nos projetos de sistemas de informao. O diagrama de implantao representa
como realizada a distribuio do sistema atravs de ns de hardware, componentes e
dependncias de software e as suas devidas relaes de comunicao.
O diagrama de implantao pode ser representado de duas formas: como descritor,
onde mostra a configurao bsica do hardware, ou como uma instncia, onde mostra as
reais caractersticas de configurao de hardware.
Os diagramas de implantao so empregados para modelagem da viso esttica de
implantao de um sistema. Com essa viso podemos analisar qual a real necessidade do
projeto para a aquisio, por exemplo, de mquinas e pacotes de software adicionais. Ou
seja, a importncia do diagrama de implantao no est somente na possibilidade de
visualizar e especificar fisicamente os sistemas, mas sim como um auxlio no gerenciamento
de projetos e sistemas de informao.
O diagrama de implantao mostra a estrutura de ns nos quais os componentes e
artefatos so implantados.
Um n um elemento do mundo real e que representa um recurso computacional.
Pode ser um dispositivo ou sistema operacional ou algum aplicativo necessrio para a
execuo do sistema. no n onde sero implementados os artefatos.
A comunicao entre ns mais utilizada a associao. Mas qualquer outro tipo de
relacionamento definido na UML pode ser utilizado. A comunicao definida ainda por um
esteretipo que descreve o tipo de comunicao que estabelecida.

Artefatos

Um artefato a especificao de um conjunto concreto de informaes que
utilizado ou produzido por um processo de desenvolvimento de software, ou para a
instalao ou operao de um sistema computacional. Exemplos de artefatos incluem
arquivos de modelos, arquivos de cdigo-fonte, scripts, arquivos executveis, tabelas em
bancos de dados, documento de texto, mensagem de e-mail ou qualquer outro resultado de
um processo de desenvolvimento.
Um artefato representa, portanto, um elemento concreto do mundo fsico. Uma
instncia particular do artefato (ou cpia do artefato) instalada em uma instncia de um
n. Artefatos podem manter associaes com outros artefatos que podem estar aninhados
dentro de si prprio. Diversos esteretipos esto previstos na norma, especificando o tipo de
artefato. Por exemplo, source ou executable. Estes esteretipos podem ser ainda
especializados mais ainda em um profile. Por exemplo, o esteretipo jar poderia ser
definido como uma subclasse de executable de forma a designar arquivos Java
executveis.


Figura 1: Exemplo de um artefato.


Figura 2: Constituio de um artefato.
Na linguagem UML, um artefato apresentado utilizando-se o retngulo de uma
classe ordinria, com o uso da palavra-chave artifact. Alternativamente, este retngulo
pode acrescentar ainda um pequeno cone no canto superior direito do retngulo.

Ns

Um n um recurso computacional onde artefatos podem ser instalados para
posterior execuo. Ns podem ser interconectados por meio de conexes que definem
estruturas de redes. Estas conexes representam caminhos de comunicao possveis entre os
ns. Topologias especficas de redes podem ser definidas por meio dessas conexes. Ns
hierrquicos (ou seja, ns dentro de ns) podem ser definidos utilizando-se associaes do
tipo composio, ou definindo-se uma estrutura interna para aplicaes de modelagem
avanada.
Arcos tracejados com o uso do keyword deploy podem ser utilizados para
representar a capacidade de um n de suportar um determinado tipo de artefato.
Alternativamente, isso pode ser representado utilizando-se artefatos aninhados dentro do n.
Em ambos os casos, isso significa que o artefato correspondente encontra-se instalado no n.


Figura 3: Exemplo da notao de um n.



Figura 4: Exemplo de artefatos instalados em um n.

Ns podem ainda receber esteretipos, para representar diferentes tipos de
plataformas de execuo. Exemplos de esteretipos desse tipo incluem os esteretipos
device para representar plataformas de hardware e executionEnvironment para
representar plataformas de software com ambientes executveis.

Caractersticas do Diagrama

Pode representar a estrutura da plataforma em que ser utilizado;
Pode representar bancos de dados, componentes de terceiros;
Pode representar os servidores, a rede;
Pode representar a configurao dos equipamentos.

Diagrama de Componentes

A linguagem UML especifica um conjunto de construtos que podem ser utilizados
para definir sistemas de software de tamanho e complexidade arbitrrios. Em particular,
define-se o conceito de componente, como uma unidade modular com um conjunto de
interfaces bem definidas, que pode ser substitudo dentro de seu ambiente. O conceito de
componente oriundo da rea de desenvolvimento baseado em componentes, onde um
componente modelado durante o ciclo de desenvolvimento e refinado sucessivamente
durante a instalao e execuo do sistema.
Um aspecto importante do desenvolvimento baseado em componentes o reuso de
componentes previamente construdos. Um componente pode ser considerado como uma
unidade autnoma dentro de um sistema ou subsistema. Ele deve possuir uma ou mais
interfaces, que podem ser potencialmente disponibilizadas por meio de portas, e seu interior
normalmente inacessvel. O acesso a um componente deve ocorrer nica e exclusivamente
por meio de suas interfaces. Apesar disso, um componente pode ser dependente de outros
componentes, e a linguagem UML prov mecanismos para representar essa dependncia,
indicando as interfaces que um componente demanda de outros componentes. Esse
mecanismo de representao de dependncias torna o componente uma unidade
encapsulada, de forma que o componente pode ser tratado de maneira independente. Como
resultado disso, componentes e subsistemas podem ser reutilizados de maneira bastante
flexvel, sendo substitudos por meio da conexo de diversos componentes por meio de suas
interfaces e dependncias.
A linguagem UML suporte a especificao tanto de componentes lgicos (e.g.
componentes de negcios, componentes de processo) como de componentes fsicos (e.g.
componentes EJB, componentes CORBA, componentes COM+ ou .NET, componentes
WSDL, etc), junto com os artefatos que os implementam e os ns em que esses componentes
so instalados e executados.
Um componente possui um carter hierrquico, que pode ser explorado no processo
de construo de um sistema. Desta forma, um componente pode ser visto, do ponto de vista
externo, como um elemento executvel do sistema, que se conecta com outros componentes
para integrar a composio deste sistema. Por outro lado, de uma perspectiva interna, um
componente pode ser visto como tambm um conjunto integrado de componentes menores
que se integram, constituindo o componente em seu nvel superior. Dessa forma, um
componente representa uma parte modular de um sistema que encapsula seu contedo e cuja
manifestao pode ser substitudo no ambiente em que se insere.
Um componente define seu comportamento por meio da definio de suas interfaces
disponibilizadas e das interfaces de que depende. Dessa forma, um componente pode ser
substitudo por outro componente que possua um mesmo conjunto de interfaces
disponibilizadas. A construo de um sistema envolve a montagem de componentes, uns aos
outros, por meio de suas interfaces. Um arranjo de componentes montado desta maneira,
constitui-se de um artefato. Artefatos podem ser instalados em diferentes ambientes de
execuo e colocados em execuo nestes.
Um componente uma unidade auto-contida que encapsula o estado e o
comportamento de um grande nmero de objetos. Um componente especifica um contrato
formal dos servios que prov a seus clientes e dos servios que necessita de outros
componentes em termos de suas interfaces disponibilizadas e requeridas.
Um componente uma unidade substituvel que pode ser remanejada tanto durante
o design como na implementao, por outro componente que lhe seja funcionalmente
equivalente, baseado na compatibilidade entre suas interfaces. De modo similar, um sistema
pode ser estendido adicionando-se novos componentes que tragam novas funcionalidades. As
interfaces disponibilizadas e requeridas podem ser organizadas opcionalmente por meio de
portas. Portas definem um conjunto de interfaces disponibilizadas e requeridas que so
encapsuladas de maneira conjunta.
Certo nmero de esteretipos padro so previstos para serem utilizados com
componentes. Por exemplo, o esteretipo subsystem pode ser utilizado na modelagem de
componentes de larga escala. Os esteretipos specification e realization podem ser
utilizados para representar componentes com especificaes e realizaes distintas, onde uma
nica especificao pode ter mltiplas realizaes.
A notao UML para um componente segue a notao de uma classe estereotipada
com o esteretipo component. Opcionalmente, no canto superior direito, pode-se incluir
um cone especfico, constitudo por um retngulo maior e dois pequenos retngulos menores
sobressaindo-se em seu lado esquerdo. Essa representao pode ser visualizada na figura a
seguir.

Figura 5: Exemplo da Notao de um Componente, com sua Interface disponibilizada.

Na figura a seguir, apresenta-se um componente com suas interfaces disponibilizadas
e requeridas. Neste exemplo, o componente Order disponibiliza as interfaces ItemAllocation
e Tracking, e requer as interfaces Person, Invoice e OrderableItem.


Figura 6: Exemplo da Notao de um Componente com Interfaces Disponibilizadas e Requeridas.

A figura a seguir apresenta outras notaes para componentes, com diferentes
compartimentos modelando diferentes aspectos do componente. Em ambos os casos, as
interfaces dispobilizadas e requeridas esto representadas internamente em compartimentos,
ao invs de externamente, por meio da conexo com interfaces.


Figura 7: Outros Exemplos de Notao para Componentes.

A figura a seguir apresenta uma outra notao alternativa, onde as interfaces
disponibilizadas e requeridas so modeladas detalhadamente.


Figura 8: Notao para Componentes com Interfaces Detalhadas.
A figura a seguir apresenta a estrutura interna de um componente, realizado pela
composio de diversos outros componentes. Observe como as interfaces requeridas de
alguns componentes so interligadas s interfaces disponibilizadas por outros componentes,
para a montagem do componente de nvel superior.


Figura 9: Perspectiva Interna de um Componente.
Observe tambm na figura acima, a definio de portas, representadas como
pequenos quadrados onde as interfaces requeridas e disponibilizadas so conectadas aos
componentes.

Diagrama de Comunicao

Este diagrama era conhecido como Diagrama de Colaborao at a verso 1.5 da
UML, tendo o seu nome modificado para Diagrama de Comunicao a partir da verso 2.0 e
est amplamente associado ao Diagrama de Sequncia, na verdade um complementa o
outro. As informaes mostradas no Diagrama de Comunicao, so com frequncia,
praticamente as mesmas apresentadas no Diagrama de Sequncia, porm com um enfoque
diferente, visto que este diagrama no se preocupa com a linha de tempo do processo,
concentrando-se em como os objetos so vinculados e quais mensagens trocam entre si
durante o processo.



O Diagrama de Comunicao tambm suporta atores e condies, sendo estas
representadas entre colchetes. As mensagens trocadas podem ser enumeradas para indicar a
sua ordem.
Setas (): troca de mensagem (chamada) de mtodos, que podem ser
enumeradas;
Reta (___): vnculo entre dois objetos;
Colchetes ([ ]): condio.

Diagrama de Estrutura Composta

Este diagrama utilizado para modelar colaboraes. Uma colaborao descreve
uma viso de um conjunto de entidades cooperativas interpretadas por instncias que
cooperam entre si para executar uma operao especfica. Este diagrama tambm pode ser
utilizado para definir a estrutura interna de um classificador.
Um classificador um elemento de modelo que descreve caractersticas estruturais e
comportamentais. Seus tipos incluem: associao, classe e interface, sendo as classes seu tipo
mais comumente usado.

Diagrama de Perfil

um diagrama auxiliar da UML que permite definir esteretipos de customizados,
valores pr-definidos e restries. O mecanismo de perfil foi definido na UML para fornecer
um mecanismo de extenso leve para o padro UML. Os perfis permitem adaptar o
metamodelo UML para diferentes plataformas (como J2EE ou. NET), ou domnios (como o
tempo real ou empresa de modelagem de processos).

Notaes (no esquecer)



Anotaes
________________________________________________________________________