Apostila Curso Oo

Projeto Orientado a Objetos - UML
ANLISE E PROJETO
ORIENTADOS A OBJETOS -
UML
Thelma Elita Colanzi
UNIPAR 09/99
Anlise e Projeto Orientados a Objetos - UML 2
ndice
1. INTRODUO.....................................................................................................................................3
1.1 HISTRIA DA ABORDAGEM OO.......................................................................................................3
1.2 CONCEITOS BSICOS DO PARADIGMA ORIENTADO A OBJETOS.......................................................3
1.3 MTODOS ORIENTADOS A OBJETOS.................................................................................................6
2. A UML...................................................................................................................................................7
2.1 HISTRICO DA UML........................................................................................................................7
2.2. O ESCOPO DA UML........................................................................................................................8
2.3. NOVAS CARACTERSTICAS DA UML...............................................................................................8
3. O CONJUNTO DE DOCUMENTOS UML.....................................................................................9
3.1. UML SUMMARY..............................................................................................................................9
3.2. UML SEMANTICS............................................................................................................................9
3.3. UML NOTATION GUIDE..................................................................................................................9
3.4. UML PROCESS EXTENSIONS.........................................................................................................10
4. A NOTAO UML...........................................................................................................................10
4.1. ORGANIZAO DO DOCUMENTO...................................................................................................10
4.2 NOTAO GENRICA.....................................................................................................................10
4.2.1. Notas....................................................................................................................................11
4.2.2. Restries.............................................................................................................................11
4.2.3. Packages..............................................................................................................................11
4.2.4. Nome....................................................................................................................................11
4.2.5. Rtulo...................................................................................................................................12
4.2.6. Property String....................................................................................................................12
4.2.7. Esteretipos.........................................................................................................................13
4.3. DIAGRAMAS DE ESTRUTURA ESTTICA........................................................................................13
4.3.1. Diagrama de Classe............................................................................................................13
4.3.2. Diagrama de Objetos..........................................................................................................13
4.3.3 Classes..................................................................................................................................14
4.3.4. Atributo................................................................................................................................14
4.3.5. Operao.............................................................................................................................15
4.3.6. Associao...........................................................................................................................16
4.3.7. Associaes N-rias............................................................................................................17
4.3.8. Composio.........................................................................................................................18
4.3.9. Generalizao......................................................................................................................19
4.3.10. Dependncia......................................................................................................................20
4.4. DIAGRAMAS DE CASO DE USO......................................................................................................21
4.5. DIAGRAMAS DE SEQNCIA..........................................................................................................23
4.7. DIAGRAMAS DE COLABORAO...................................................................................................25
4.8. DIAGRAMA DE ESTADO.................................................................................................................27
4.9. DIAGRAMA DE ATIVIDADE............................................................................................................30
4.9.1. Estado Ao.........................................................................................................................30
4.9.2. Decises...............................................................................................................................31
4.9.3. Swinlanes.............................................................................................................................32
4.10. DIAGRAMAS DE IMPLEMENTAO...............................................................................................33
4.10.1. Diagramas de Componentes.............................................................................................33
4.10.2. Diagramas de Disponibilidade.........................................................................................34
5. CONCLUSO....................................................................................................................................36
6. REFERNCIAS BIBLIOGRFICAS............................................................................................37
ANEXO A..................................................................................................................................................38
A
1. Introduo
Sob um ponto de vista superficial, a expresso orientado a objetos significa que o
software organizado como uma coleo de objetos separados que incorporam tanto a
estrutura quanto o comportamento dos dados. Isso contrasta com a programao
convencional, segundo a qual a estrutura e o comportamento dos dados tm pouca vinculao
entre si.
1.1 Histria da Abordagem OO

Inicialmente, no fim da dcada de 60, a programao orientada a objetos foi discutida
pelos programadores que trabalhavam com a linguagem Simula. Nos anos 70, ela foi uma parte
importante da linguagem Smalltalk desenvolvida pela Xerox PARC. Nessa poca, a anlise
estruturada era usada para a anlise e projeto de software e as linguagens de programao mais
utilizadas eram Cobol e Fortran. Poucas pesquisas enfatizavam o projeto orientado a objetos e
praticamente nenhuma enfocava a anlise orientada a objetos (Yourdon & Coad, 1991).
Nos anos 80, Bjarne Stroustrup da AT&T Bell Laboratories estendeu a linguagem C
para criar C++, uma linguagem que apia a programao orientada a objetos. Essa linguagem
se tornou popular, pois no foi feita somente para microcomputadores, mas para a maioria das
arquiteturas de computadores. No incio da dcada de 80 verses comerciais da linguagem C+
+ da AT&T propiciaram a difuso da programao orientada a objetos na comunidade de
software em geral. Pois, com C++ os programadores estavam aptos a aprender a orientao a
objetos sem ter que investir em ambientes e linguagens de computao novos e diferentes
(Winblad et al., 1990).
Um dos primeiros materiais sobre anlise orientada a objetos foi publicado por Sally
Shlaer e Stephen Mellor (Shlaer & Mellor, 1988). O nmero de linguagens de modelagem para
anlise orientada a objetos aumentou de menos de 10 para mais de 50 durante o perodo entre
1989 e 1994. Muitos usurios de mtodos OO tiveram problemas para se satisfazer totalmente
com uma das linguagens de modelagem disponveis, iniciando a chamada guerra dos
mtodos. Pelo meio da dcada de 90, alguns mtodos comearam a incorporar tcnicas uns
dos outros e, dessa forma, alguns deles emergiram como, por exemplo, o mtodo de Booch
(Booch, 1993), o Fusion (Coleman et al., 1994) e a UML (Rational, 1997a).
1.2 Conceitos Bsicos do Paradigma Orientado a Objetos

A orientao a objetos muda o foco do processo de programao de procedimentos
para objetos e classes, alm de incorporar um conjunto de conceitos, tais como herana,
polimorfismo e encapsulamento de dados, que so definidos a seguir.
Objetos so mdulos que contm tanto os dados como os procedimentos que agem
sobre os dados. Um pargrafo de um documento, uma janela na minha estao de trabalho e a
rainha branca em um jogo de xadrez so exemplos de objetos. Os objetos podem ser
concretos, como um arquivo em um sistema de arquivos, ou conceituais, como uma norma de
escalonamentos em um sistema operacional de multiprocessamento. Cada objetos tem sua
prpria identidade, que lhe inerente. Em outras palavras, dois objetos so distintos mesmo
que todos os valores de seus atributos (como nome e tamanho) sejam idnticos. No mundo
real um objeto limita-se a existir, mas, no que se refere a uma linguagem de programao, cada
objeto dispe de um nico indicador, pelo qual ele pode ser inequivocamente referenciado. O
indicador pode ser implementado de diversas maneiras, como um endereo, um elemento de
uma matriz ou um valor exclusivo de um atributo. As referncias dos objetos so uniformes e

independentes do contedo dos mesmos, permitindo a criao de colees de objetos
mesclados, tal como um diretrio de um sistema de arquivos que contenha tanto arquivos
quanto subdiretrios.
Os procedimentos contidos nos objetos ganham um novo nome - mtodos. Os objetos

podem agir e ser ativados e modificados por mensagens de outros objetos. Uma mensagem
uma solicitao para que o objeto execute uma de suas operaes (mtodos).
Os objetos com a mesma estrutura de dados(atributos) e o mesmo comportamento

(operaes) so agrupados em uma classe. Pargrafo, Janela e PeadeXadrez so exemplos de
classes. Uma classe uma abstrao que descreve propriedades importantes para uma
aplicao ignorando o restante. Qualquer escolha de classes arbitrria e depende da
aplicao. Uma Classe consiste de uma interface que caracteriza os objetos e define a lista de
operaes permitidas a um objeto daquela classe; da implementao destas operaes,
chamadas de mtodos ou funes membro; e, das instncias de variveis que armazenam o
estado de um objeto.
Cada classe descreve um conjunto possivelmente infinito de objetos individuais. Cada
objeto dito ser uma instncia de sua classe. Cada instncia de classe tem seu prprio valor
para cada atributo, mas compartilha os nomes de atributos e operaes com outras instncias
da mesma classe. A Figura 1 mostra duas classes e alguns de seus respectivos objetos
representativos de instncias. Um objetos contm uma referncia implcita sua prpria classe;
ele sabe que tipo de coisa ele .
Herana o compartilhamento de atributos e operaes (mtodos) entre classes com
base em um relacionamento hierrquico. A relao de herana entre classes permite que a
definio e a implementao de uma classe sejam baseadas nas definies de outras classes j
existentes. Com a utilizao de herana, as classes so inseridas em uma hierarquia de
especializao, de tal forma que uma classe mais especializada herde todas as propriedades da
classe mais geral a que ela imediatamente se subordina na hierarquia. A classe mais geral
denominada de superclasse, classe-pai ou classe-base e a classe mais especializada
denominada subclasse ou classe-filho. A herana o mecanismo pelo qual uma classe-filho
herda caractersticas de sua classe-pai e as estende ou restringe de algum modo, ou seja, ela
herda todas as propriedades da superclasse e acrescenta suas prprias e exclusivas
caractersticas. As propriedades da superclasse no precisam ser repetidas em cada subclasse.
Por exemplo, JanelaRolante e JanelaFixa so subclasses de Janela. Essas duas subclasses
herdam as propriedades de Janela, como uma regio visvel na tela. JanelaRolante acrescenta
uma barra de paginao e um afastamento. A capacidade de identificar propriedades comuns a
vrias classes de uma superclasse comum e de faz-las herdar as propriedades da superclasse
pode reduzir substancialmente as repeties nos projetos e programas e uma das principais
vantagens dos sistemas orientados a objetos.
Figura 1 Exemplos de Classes e Objetos
Nesse contexto, cada classe declarada como uma subclasse de uma ou mais
superclasses. Quando existe mais de uma superclasse, a relao de herana denominada
herana mltipla. Podem existir problemas de conflito entre informaes herdadas por uma
subclasse provenientes de diferentes superclasses, como por exemplo, serem herdadas variveis
com mesmo nome, mas de tipos diferentes. Este tipo de conflito j tratado pela maioria das
linguagens orientadas a objetos. Na Figura 2 encontra-se um exemplo ilustrativo das relaes
de herana e de herana mltipla. A classe R herda caractersticas da classe S1 e da classe S2.
A classe T herda caractersticas das classes R e S. Tanto a classe R como a classe T
caracterizam a Herana Mltipla. A classe S herda caractersticas apenas da classe S3,
determinando a Herana Simples.
O Polimorfismo geralmente representa a qualidade ou estado de um objeto ser capaz

de assumir diferentes formas. Quando aplicado s linguagens de programao indica que a
mesma construo da linguagem pode assumir diferentes tipos ou manipular objetos de
diferentes tipos. Por exemplo, um operador + pode ser usado com inteiros, pontos-
flutuantes, ou at mesmo strings (Morandini, 1996). Um outro exemplo a operao mover
que pode atuar diferentemente nas classes Janela e PeadeXadrez.
Class S1: Class S2: Class S3:

Methods: M, N, ... Methods: N, ... Methods: N, ...
Class R: Class S:
Methods: ... Methods: ...
Class T:
Methods: ...
Figura 2 - Exemplo das Relaes de Herana e Herana Mltipla
O comportamento de uma classe especificado e utilizado nos mtodos associados s

instncias dessa classe. Os mtodos ou funes membro so operaes que podem utilizar
e/ou atualizar o estado de um objeto. Em uma hierarquia de herana, um mtodo definido por
uma classe herdado por suas subclasses; o que implica que os mtodos herdados sejam parte
da interface que manipula as instncias da subclasse e possam ser invocados por elas. Com a
finalidade de manter a interface e a implementao dos mtodos separadas pode ser utilizada a
tcnica de encapsulamento de dados.
Encapsulamento de dados uma tcnica empregada para garantir o ocultamento de

informaes, em que a interface e a implementao de uma unidade so sintaticamente
separadas. Desta forma, somente os prprios mtodos do objeto podero fazer acesso aos
dados encapsulados. Isso permite ao programador esconder as decises de projeto dentro da
implementao e apontar as possveis interdependncias com outros componentes da interface.
O encapsulamento encoraja a modularidade do programa, isola as unidades desenvolvidas e
restringe as implicaes de possveis mudanas. Em particular, se um programador mudar a
implementao de uma unidade, mantendo a interface da mesma, as outras unidades no
devem ser afetadas por essa mudana.
No projeto de sistemas a abstrao permite concentrar-se somente no que um objeto

e faz, antes de decidir como ele deve ser implementado. O uso da abstrao preserva a
liberdade de se tomar decises evitando, tanto quanto possvel, comprometimentos prematuros
com detalhes.
1.3 Mtodos Orientados a Objetos

Embora existam muitos mtodos de desenvolvimento orientados a objetos e cada um
tenha as suas particularidades, todos eles tm o objetivo de oferecer mecanismos que captem
melhor as informaes para a elaborao de um modelo, a partir do mundo real, a fim de
melhorar a manutenibilidade e o entendimento de sistemas. O mtodo Fusion (Coleman et al.,
1994), OMT, o mtodo de Booch, o TeamFusion (TeamFusion, 1997) e o Unified Process
(Jacobson et al., 1999) so exemplos de mtodos orientados a objetos. O Unified Process e o
TeamFusion, que uma extenso do mtodo Fusion, utilizam a UML Unified Modeling
Language (Rational, 1997a) como notao.
Os mtodos envolvem atividades a serem realizadas em cada fase do ciclo de vida do

software, incluindo os modelos (diagramas) que devem ser produzidos em cada fase.
Geralmente os mtodos possuem um processo e uma notao. Um processo envolve as fases
do ciclo de vida (por exemplo, Anlise, Projeto e Implementao) determinando para cada fase
quais modelos ou diagramas devem ser construdos. A notao de um processo a forma
como os elementos dos modelos devem ser representados.
2. A UML
A motivao para o desenvolvimento da UML foi integrar as melhores prticas da
indstria de software, incluindo vises amplamente variadas baseadas nos nveis de abstrao,
domnios, arquiteturas, estgios do ciclo de vida, tecnologias de implementao, etc.
A UML, a Unified Modelling Language, consiste de um metamodelo e uma notao,

inteiramente descrita em uma srie de documentos disponveis pela Rational Software
Corporation. uma linguagem para especificao, construo, visualizao e documentao
dos componentes de um sistema, especialmente aqueles fortemente ligados a software. Seu

foco principal est em criar uma linguagem de modelagem padronizada, no em criar um
processo padronizado.
2.1 Histrico da UML

Pelo meio da dcada de 90, mtodos como o Booch, o OOSE, o OMT 1 e o Fusion
comearam a incorporar tcnicas uns dos outros. Cada um destes eram mtodos completos,
mas reconhecia-se que havia certos pontos mais fortes em cada um deles. Em termos simples,
o OOSE era uma abordagem orientada a uso de caso que fornecia uma excelente engenharia
de suporte a negcios e anlise de requisitos. O OMT era especialmente expressivo para
anlise e sistemas de informao com dados intensivos. Booch era particularmente expressivo
durante o design e na fases de construo de projetos e popular para aplicaes intensivas em
engenharia [Rat97-a].
O desenvolvimento da UML comeou em outubro de 1994, quando Grady Booch e Jim

Rumbaugh, ambos na Rational Software Corporation, comearam seu trabalho de unir os
mtodos Booch e OMT. Um esboo do Mtodo Unificado 0.8 (como era chamado), foi
liberado em outubro de 1995. Ainda no final de 1995, Ivar Jacobson juntou-se ao esforo de
unificao, fundindo o mtodo OOSE.
Booch, Rumbaugh e Jacobson foram motivados a criar uma linguagem de modelagem

unificada por trs razes. Primeiro, os mtodos j estavam evoluindo em direo um do outro
independentemente, assim fazia sentido continuar evoluindo juntos, eliminando o potencial
para quaisquer diferenas gratuitas e desnecessrias que poderiam confundir o usurio.
Segundo, pela unificao da notao e da semntica, eles poderiam trazer estabilidade ao
mercado orientado a objetos, permitindo que os projetos se fixassem em uma linguagem de
modelagem mais madura e deixando que os construtores de ferramentas se detessem em
prover caractersticas mais teis. Terceiro, eles esperavam que sua colaborao traria melhorias
para os trs mtodos iniciais, ajudando-os a capturar lies aprendidas e lidar com problemas
que nenhum dos trs mtodos anteriores resolvia adequadamente.
Os esforos de Booch, Rumbaugh e Jacobson resultaram na verso 0.9 e 0.91 dos

documentos da UML em junho e outubro de 1996. Durante 1996, os autores da UML pediram
e receberam feedback da comunidade geral. Eles incorporaram esse feedback, mas estava claro
que ateno adicional direcionada ainda era necessria. Um consrcio - UML Partners - foi
estabelecido entre muitas organizaes dispostas a dedicar recursos para trabalhar em direo
a uma forte definio da UML. Este consrcio foi composto pelas seguintes empresas: Digital
Equipment Corp., Hewlett-Packard, i-Logix, Intellicorp, IBM, ICON Computing, MCI
Systemhouse, Microsoft, Oracle, Rational Software, Texas Instruments e Unisys. Esta
colaborao produziu a UML 1.0, uma linguagem de modelagem que bem definida,
expressiva e poderosa, e geralmente aplicvel.
Nos documentos da UML 1.0, disponveis via world wide web

(http://www.rational.com/uml), pode ser encontrado uma lista das contribuies individuais
que cada organizao membro do consrcio fez para o resultado obtido na UML 1.0.
2.2. O Escopo da UML

A Unified Modelling Language uma linguagem para especificar, construir, visualizar
e documentar os artefatos de software.
1
Object Modelling Technique
Primeiramente, a UML funde os conceitos dos mtodos Booch, OMT e OOSE. O

resultado uma linguagem de modelagem simples, comum e amplamente til para o usurio
destes mtodos e de outros.
Segundo, os autores da UML objetivaram, em particular, a modelagem de sistemas

concorrentes e distribudos, significando que a UML contm elementos que se adequam a
esses domnios.
Terceiro, a UML focaliza uma linguagem de modelagem padro, no um processo

padro. Ainda que a UML deva ser aplicada no contexto de um processo, fato que diferentes
organizaes e domnios problemas requerem diferentes processos. Por isso, os esforos foram
concentrados primeiramente sobre um metamodelo comum e em seguida, sobre uma notao
comum.
2.3. Novas Caractersticas da UML

Os esforos de unificao tinham como meta manter a simplicidade, excluir elementos
do Booch, OMT e do OOSE que no funcionavam na prtica, adicionar elementos de outros
mtodos que foram mais efetivos e criar novos elementos apenas quando uma soluo no
estava disponvel.
Diversos conceitos novos foram includos[Rat97-a]:

Esteretipos
Responsabilidades
Mecanismos de extenso: esteretipos, tagged value, restries
Threads e processos
Distribuio e concorrncia
Patterns / colaboraes
Diagramas de atividade
Clara distino entre tipo, classe e instncia
Refinamento (para manipular relacionamentos entre nveis de abstrao)
Interfaces e componentes
3. O Conjunto de Documentos UML

A Unified Modelling Language composta pelos seguintes documentos: UML
Summary, UML Semantics, UML Notation Guide, e UML Process-Specific Extensions. O
contexto de cada um destes documentos brevemente descrito a seguir.
3.1. UML Summary

Constitui-se numa introduo a UML, que visa apresentar as motivaes para o projeto
e um sumrio dos resultados obtidos at agora.
3.2. UML Semantics

Este documento descreve o modelo preciso que est por baixo da UML, apresentado
tanto textualmente como na prpria notao UML. Os desenvolvedores da UML comearam
com um metamodelo preciso, usando a notao UML complementada por textos em ingls. O
propsito do metamodelo era prover um enunciado nico, simples e definitivo para a sintaxe e
a semntica dos elementos da UML. Os autores esperam selecionar pessoas para expressar
esse metamodelo mais precisamente, descrevendo sua semntica usando tcnicas formais.
Um metamodelo uma linguagem para especificar um modelo, neste caso, um modelo

de objetos. Metamodelos so importantes porque eles podem proporcionar uma afirmao
nica, simples e sem ambigidades da sintaxe e da semntica de um modelo. O nvel de meta
em um modelo um tanto arbitrrio, e os desenvolvedores da UML conscientemente
escolheram um nvel semanticamente rico, porque tal nvel necessrio para permitir a
concordncia semanticamente rica que necessria para o intercmbio de ferramentas e para o
projeto de sistemas complexos.
3.3. UML Notation Guide

O guia de notao descreve a notao UML e apresenta exemplos. A notao grfica e
a sintaxe textual so as partes mais visveis da UML, usadas por desenvolvedores e
ferramentas para modelar sistemas. Elas so representaes de um modelo no nvel do usurio,
o que corresponde semanticamente a uma instncia do metamodelo UML. Em termos de
vises de um modelo , a UML define os seguintes diagramas grficos:
diagrama de casos de uso
diagrama de classe
diagramas de comportamento
diagrama de estado
diagrama de atividade
diagrama de seqncia
diagrama de colaborao
diagramas de implementao
diagrama de componente
diagrama de disponibilidade
Esses diagramas fornecem mltiplas perspectivas do sistema sob anlise ou
desenvolvimento. O modelo subjacente integra essas perspectivas de forma que um sistema
consistente possa ser analisado e construdo. Estes diagramas, juntamente com a
documentao de suporte, so os artefatos primrios que um modelador v, ainda que a UML
e as ferramentas de suporte forneam diversas vises derivadas.
3.4. UML Process Extensions

Este documento propem certos valores processo-especfico dos mecanismos de
extenso da UML (por exemplo: esteretipos, tagged values, e restries), bem como suas
ilustraes associadas, se existir uma.
4. A Notao UML
O documento referente a notao UML apresenta a representao visual da notao.
Apesar de conter uma breve explanao da semntica de cada construo, ele deve ser usado
em conjunto com a UML Semantics, que deve ser consultado para detalhes completos sobre a
semntica. A descrio de toda a notao UML apresentada a seguir foi extrada do
documento original[Rat97-d].
4.1. Organizao do Documento

Os diagramas esto agrupados pelo tipo (esttico, atividade, caso de uso, seqncia, de
estado, colaborao e implementao). Dentro de cada tipo de diagrama so listados os
elementos de modelagem que se encontram no diagrama e sua representao. Cada um dos
elementos de modelagem e construes notacionais importantes contm uma explanao
dividida nos seguintes itens:
Semntica Breve resumo da semntica. Para maiores explicaes

deve-se consultar o documento referente a semntica.
Notao Explica os elementos notacionais da caracterstica.
Opes de Apresentao Descreve vrias maneiras de apresentar a informao no

modelo, tais como a habilidade para suprimir ou filtrar
informao, modos alternados de mostrar as coisas, e
sugestes para alternar as formas de apresentao da
informao em ferramentas.
Guidelines de Estilo Sugestes para o uso de marcas estilizadas, tais como

fontes, convenes de nomes, o arranjo dos smbolos,
etc., que no so explicitamente parte da notao mas
que ajudam a tornar os diagramas mais legveis.
4.2 Notao Genrica

A notao UML basicamente bidimensional. A maioria dos diagramas so grafos
contendo ns conectados por caminhos. Caminhos so segmentos de linha com ambos os
pontos finais conectados. Caminhos esto sempre ligados a outros smbolos em ambos os
extremos.
4.2.1. Notas
Uma nota um comentrio posto no diagrama. Ela conectada ao diagrama e no a
elementos do modelo, a menos que seja estereotipada para ser uma restrio.
Isto uma
nota!
Figura 2. Exemplo de Nota
4.2.2. Restries
Uma restrio uma relao semntica entre os elementos do modelo que especificam
condies e proposies que devem ser mantidas como verdadeiras. Uma restrio representa
uma informao semntica conectada a um elemento do modelo, no apenas a uma viso dele.
Uma restrio mostrada como uma string textual entre chaves ( { } ). A UML no
prescreve a linguagem em que a restrio escrita.
Para um elemento do tipo string (tal como um atributo) a string de restrio pode vir
aps a string do elemento.
Para uma lista de elementos do tipo string (como atributos dentro de uma classe) a
string de restrio aparece como um dos elementos da lista, se aplica a todos os elementos que
a sucedem e continua sendo vlida at o aparecimento de outra restrio ou o trmino da lista.
Para um nico smbolo grfico (como uma classe ou um caminho de associao) a

string de restrio pode ser colocada perto do smbolo, preferivelmente prximo ao nome do
smbolo, se houver.
Para dois smbolos grficos (como duas classes ou duas associaes) a restrio
mostrada como uma seta pontilhada e um elemento para o outro rotulada pela string de
restrio. A direo da seta uma informao relevante dentro da restrio.
Para trs ou mais smbolos grficos a string de restrio colocada dentro de uma
nota e conectada a cada um dos smbolo por linhas pontilhadas.
4.2.3. Packages
Um package um agrupamento de elementos do modelo. Packages podem ser
agrupados em outros packages. O sistema todo pode ser pensado como um nico package de
alto nvel com tudo dentro. Todos os tipos de elementos de modelagem e diagramas UML
podem ser organizados em packages.
4.2.4. Nome
Um nome uma string usada para identificar um elemento do modelo dentro de algum
escopo. Um nome de caminho (pathname) usado para encontrar um elemento do modelo a
partir da raiz do sistema (ou a partir de qualquer outro ponto). Um nome um seletor
(qualificador) dentro de um escopo. Um pathname uma srie de nomes linkados por um
delimitador.
Exemplo de pathname:
MathPak :: Matrices :: BandedMatrix.dimension
Figura 3. Pacotes
4.2.5. Rtulo
Um rtulo uma string que est conectada a um smbolo grfico.
4.2.6. Property String

Uma property string uma string usada para mostrar propriedades de certos elementos
do modelo. Por meio dela qualquer valor pode ser conectado a um elemento do modelo,
incluindo atributos, associaes e tagged values.
Um tagged value um par palavra_chave - valor, que pode ser conectado a qualquer
tipo de elemento de modelagem. A palavra_chave chamada de tag. Cada tag representa um
tipo particular de propriedade aplicvel a um ou vrios elementos de modelagem. Ambos, tag e
valor, so codificados como strings. Tagged values so um mecanismo de extenso da UML
que permite que informaes arbitrrias sejam conectadas ao modelos.
Uma property string mostrada como uma seqncia de property specifications

separadas por vrgula e entre chaves ( {} ).
Uma property specification tem a forma: palavra_chave = valor, onde

palavra_chave uma propriedade e valor uma string que denota seu valor.
Se a propriedade tem valor booleano, seu default verdadeiro, caso no seja

especificado valor.
Exemplo de property string:
{ author=Joe Smith, deadline=31/03/1997, status=analysis }
Exemplos de tagged value:

{valor >100} (pr-condio para a execuo de um mtodo)
{Abstract} ( Indica que a classe nunca deve ser instanciada)
4.2.7. Esteretipos
Um esteretipo um mecanismo de extenso introduzido pela UML, que permite que o
usurio estenda o metamodelo para suprir necessidades que no encontram-se entre os
metaelementos disponveis, desde que a definio semntica da prpria linguagem no seja
ferida. uma nova classe de elemento de modelagem que introduzido no modelo em tempo
de modelagem. H certas restries sobre o que um esteretipo pode ser: ele deve ser baseado
em certas classes existentes no metamodelo e ele deve estender estas classes apenas em certas
formas pr-definidas, porm estes limites no so claramente especificados.
A apresentao geral de um esteretipo o nome do esteretipo colocado entre os

smbolos << >>. A string esteretipo pode ser colocada sobre ou em frente do nome do
elemento do modelo que est sendo descrito.
Um esteretipo pode ser aplicado a classes, relacionamentos de dependncia (como um

refinamento), atributos, operaes, etc.
Existe tambm uma representao grfica para os esteretipos: um cone que pode ser
usado em conjunto ou no com a string esteretipo, como parte do smbolo para o elemento
do modelo no qual o esteretipo se baseia.
Figura 4. Vrias notaes de esteretipos
4.3. Diagramas de Estrutura Esttica
4.3.1. Diagrama de Classe

Um diagrama de classe uma coleo de elementos estticos do modelo declarativo, tais como
classes, tipos, e seus relacionamentos, conectados uns aos outros e aos seus contedos como
um grafo.
4.3.2. Diagrama de Objetos

Um diagrama de objetos um grafo de instncias. Um diagrama de objetos esttico uma
instncia de um diagrama de classe. Ele mostra o estado detalhado do sistema em um ponto no
tempo. Um diagrama de objetos dinmico mostra em detalhes o estado do sistema sobre um
certo perodo de tempo, incluindo mudanas que ocorrem sobre o tempo. Diagramas de
objetos dinmicos so mostrados como diagramas de colaborao. Na Figura 5 so
apresentados um Diagrama de Classes e um possvel Diagrama de Objetos para ele.
Autor Computador
Usa
nome: String nome: String Diagrama de
idade: Integer memria:Integer Classes
0..1 1..*
PC Profissional de
Bob: Computador
nome: Dell 466
Bob: Autor memria: 64
nome: Bob J.
idade: 32 Diagrama de
PC Domstico de Objetos
Bob: Computador
nome: Compaq
Pentium MMX
memria: 32
Figura 5 - Diagrama de Classes mostrando as classes e um Diagrama de Objetos com

instncias dessas classes
4.3.3 Classes
Uma classe um descritor para um conjunto de objetos com estrutura, comportamento
e relacionamentos similares. Nos diagramas de classes da UML uma classe representada por
um retngulo com trs compartimentos, conforme indicado na Figura 6; o primeiro
compartimento para o nome da classe, o segundo para os seus atributos e o ltimo para as
suas operaes. As associaes so mostradas como linhas que conectam classes. Existe uma
variedade de adornos para indicar as propriedades das associaes, como nome da associao,
cardinalidade, papis, direcionamento, etc. Nomes de papis e direcionamento so teis para
deixar claro a ordem de leitura dos relacionamentos, principalmente em auto-relacionamentos.
Nome da Classe Nome da Classe
Compartimento de Compartimento de
atributos atributos
Nome da associao
Compartimento de Compartimento de
Operaes Operaes
Figura 6 Notao de Classes e Associaes
4.3.4. Atributo
Usado para mostrar os atributos em uma classe. Os detalhes de uma expresso do tipo do
atributo no especificado pela UML; eles dependem da sintaxe de expresso suportada por
uma particular especificao ou da linguagem de programao que est sendo usada.
Um atributo mostrado como uma string textual. A sintaxe padro :
visibilidade nome : tipo = valor_inicial { property string }

na qual visibilidade um dos seguintes smbolos:
+ visibilidade pblica
# visibilidade protegida
- visibilidade privada
na qual nome uma string identificadora;
na qual tipo uma especificao dependente do tipo da implementao de um atributo;
na qual valor_inicial uma expresso dependente de linguagem para o valor inicial de
um objeto criado recentemente. opcional e neste caso o sinal = tambm omitido. Um
construtor explcito para um novo objeto pode modificar o valor inicial default.
na qual property-string indica valores de propriedades que so aplicadas ao elemento.
opcional e neste caso as chaves {} tambm so omitidas.
O smbolo de visibilidade pode ser suprimido. Neste caso, a ausncia do smbolo deve
ser entendida como no mostrada e no como no definida. Na Figura 7 so apresentados
exemplos de atributos da classe Fatura.
Fatura
+ valor: Real
+ data: Date = data atual
+ cliente: String
- num_faturas: Integer = 0
+ status: String = nopago
{nopago, pago}
Figura 7 Exemplo de atributos da classe Fatura
4.3.5. Operao
Usada para mostrar operaes (mtodos) nas classes. A sintaxe a seguinte:
visibilidade nome (lista_parmetros) : tipo_retorno { property string }

na qual visibilidade nome semelhante ao apresentado para atributos;
na qual tipo_retorno uma especificao dependente do tipo da implementao do
valor retornado pela operao. Se omitido, a operao no retorna valor;
na qual lista_parmetros uma lista de parmetros formais separados por vrgula, cada
um especificado segundo a seguinte sintaxe: nome : tipo = valor-padro
na qual nome o nome do parmetro formal;
na qual tipo uma especificao dependente da implementao do tipo;
na qual valor_padro um valor opcional para o parmetro;
na qual property-string semelhante ao apresentado para atributo.
Figura
+ desenhar ()
+ escala (percentual: Integer = 25)
-pos_retorno (): position
Figura 8 Exemplo de mtodos da Classe Figura
4.3.6. Associao
Uma associao mostrada como linhas conectando smbolos de classes. A linhas
podem ter adornos que indicam suas propriedades. Associaes ternrias ou de ordens
superiores so representadas como um diamante conectado as classes por linhas. Uma
seqncia de linhas conectadas chamado de um "caminho".
Na Figura 9 apresentada a notao dos tipos de relacionamentos existentes nos

diagramas de classes da UML. Maiores detalhes a respeito da notao dos diagramas de
classes so encontrados em (Rational, 1997b).
Generalizao
Associao
Agregao
Dependncia
Navegabilidade
Figura 9 Exemplos de tipos de relacionamentos
Os caminhos podem conter os seguintes tipos de adornos:
Nome da associao. Designa um nome para a associao. opcional. mostrado

prximo ao caminho. A string pode conter um pequeno tringulo
slido indicando a direo de leitura da associao. Este
tringulo no tem nenhum significado semntico; puramente
descritivo.
Classe de associao. Designa uma associao que tem propriedades como uma classe,
tais como atributos, operaes e outras associaes. Isto est
presente se, e somente se, a associao uma classe de
associao. representado por um smbolo de classe conectado
ao caminho da associao por uma linha pontilhada.
geralmente utilizada para armazenar atributos de relacionamento.
Associao-or. Uma associao or indica uma situao na qual apenas uma das
associaes potenciais podem ser instanciadas em um certo
tempo por um nico objeto. Isto representado como uma linha
pontilhada ligando as duas ou mais associaes, as quais todas
devem ter uma classe em comum, com uma string de restrio
"{or}" rotulando a linha pontilhada.
Indicador de agregao. Um pequeno smbolo em forma de diamante colocado ao final

do caminho para designar agregao. O diamante conectado a
ponta do caminho que conecta a classe que agregada. A
agregao opcional. Se o diamante estiver preenchido, ento
est sendo representado uma forma de agregao forte chamada
de "composio".
Multiplicidade. A string de multiplicidade especifica o limite de cardinalidade

que permitido a um conjunto assumir. A multiplicidade pode ser
especificada para associaes, composies, repeties, e outros
propsitos. Essencialmente uma multiplicidade um subconjunto
aberto de inteiros no-negativos.
Figura 10. Notao para associao, classe de associao, associao-or e multiplicidade
4.3.7. Associaes N-rias

Uma associao n-ria uma associao entre trs ou mais classes. Cada instncia da
associao uma n-tupla de valores das respectivas classes. Uma associao binria um caso
especial que contm notao prpria.
Uma associao n-ria representada por um diamante grande (grande se comparado com o
terminador de caminho) com um caminho do diamante para cada uma das classes participantes.
O nome da associao, se houver, mostrado prximo ao diamante. A multiplicidade pode ser
indicada, contudo, agregaes no so permitidas.
Figura 11. Associao ternria que tambm uma classe de associao
Um smbolo de classe de associao pode ser conectado ao diamante por uma linha pontilhada.
Isto indica que a associao n-ria tem atributos, operaes e/ou associaes.
4.3.8. Composio
Uma composio uma forma de agregao com forte propriedade e tempo de vida da
parte coincidente com o todo. A agregao um tipo de associao que representa um
relacionamento que indica que uma classe parte-de uma outra classe. Um relacionamento de
composio indica que um classe composta por outras, ou seja, indica que uma classe agrega
outras.
Composio pode ser representada por um diamante slido (preenchido) como um

terminador de um caminho de uma associao. Alternativamente, a UML prov uma forma
graficamente aninhada, que em muitos casos, pode ser mais conveniente para demonstrar
composio.
Figura 12 Exemplo de Composio
Figura 13. Diferentes formas de representar composio
4.3.9. Generalizao
Generalizao um relacionamento entre um elemento mais geral e um elemento mais
especifico que totalmente consistente com o primeiro elemento e contm informaes
adicionais. A generalizao utilizada para representar relacionamentos de herana. usado

para classes, pacotes, casos de uso, e outros elementos.
A generalizao representada como um caminho (uma linha slida) do elemento mais

especifico (tal como uma subclasse) para o elemento mais geral (como uma superclasse), com
um tringulo no final do caminho, onde este encontra o elemento mais geral.
Um grupo de caminhos de generalizao para uma dada superclasse pode ser

representado como uma rvore com segmentos compartilhados (inclusive o tringulo) para a
superclasse, ramificando-se em mltiplos caminhos para cada subclasse. Um exemplo de
generalizao apresentado na Figura 14.
Figura 14 Exemplo de Generalizao
Se um rtulo colocado sobre o tringulo de generalizao compartilhado por vrios

caminhos de generalizao para subclasses, o rtulo aplica-se a todos os caminhos.
A existncia de subclasses adicionais em um modelo e que no esto sendo mostradas

em um diagrama particular pode ser representada pelo sinal de reticncias (...) no lugar dessas
subclasses. importante ressaltar que este sinal no indica que classes adicionais possam ser
conectadas futuramente. Indica que classes adicionais existem mas no esto sendo mostradas
no momento.
Figura 15. Estilos de representar generalizao
4.3.10. Dependncia
Uma dependncia indica uma relao semntica entre dois (ou mais) elementos do modelo. Ela
relaciona os prprios elementos do modelo e no requer um conjunto de instncias para ter
significado. Ela indica uma situao em que uma mudana no elemento alvo pode requerer
uma mudana no elemento fonte na dependncia.
Uma dependncia mostrada como uma seta pontilhada de um elemento para outro elemento
do modelo, onde o primeiro elemento o dependente. A seta pode ser rotulada opcionalmente
com um esteretipo ou um nome.
Figura 16. Vrias dependncias entre classes.
Dependncia entre packages tambm permitida.
Na Figura 17 apresentado um diagrama de classes parcial para o sistema

SAPES, um sistema de apoio escrita que auxilia um pesquisador no gerenciamento da sua
base de dados bibliogrfica, cuja especificao se encontra no Anexo A.
Item Bibliogrfico
Pesquisador insere
1 *
composta de Bibliografia
*
autor
ttulo
data
editora
1
1
cria
possui
* Sinnimo
*
Figura 17 Diagrama de Classes parcial do SAPES
4.4. Diagramas de Caso de Uso

Um diagrama de caso de uso mostra o relacionamento entre os atores e os casos de uso
dentro de um sistema. Um ator uma entidade externa que interage com o sistema, tal como
um usurio ou um outro software. Um ator estimula o sistema com eventos de entrada ou
recebe alguma sada dele. Um caso de uso o conjunto de interaes entre o sistema e um ou
mais atores que alcanam alguns objetivos especficos. Um caso de uso sempre iniciado por
um estmulo de um ator; ocasionalmente, outros atores podem participar do caso de uso.
A seguir so apresentados alguns passos a serem seguidos para identificar casos de uso:
Baseado em Ator:
1. Passo - identificar os atores relacionados com o sistema
ou organizao;
2. Passo - para cada ator, identificar os processos que eles
iniciam ou participam.
Baseado em Eventos:
1. Passo - identificar os eventos externos para os quais o
sistema deve responder;
2. Passo - relacionar os eventos com atores e casos de uso.
Na UML um ator representado por uma figura de um homem estilizado com o nome
do ator abaixo da figura. Um caso de uso representado por uma elipse e o nome do caso de
uso pode ser colocado dentro da elipse ou abaixo dela. A comunicao entre atores e casos de
uso mostrada utilizando-se uma linha slida. O relacionamento extends mostrado por um
segmento de reta de generalizao do caso de uso mais abrangente (que estende o
comportamento) para o caso de uso base. O relacionamento uses mostrado por uma linha de
generalizao do caso de uso cliente (que usa o comportamento) para o caso de uso que est
sendo usado. Maiores detalhes sobre a notao UML para os diagramas de casos de uso
podem ser obtidas no manual da notao UML (Rational, 1997b).
Um diagrama de caso de uso um grafo de atores, um conjunto de casos de uso

fechado por um limite de sistema, associaes de comunicao (participao) entre os atores e
os casos de uso, e generalizaes entre casos de uso.
Figura 18. Exemplo de um diagrama de caso de uso

Um caso de uso representado por uma elipse contendo o nome do caso de uso. O
nome pode ser colocado abaixo da elipse.
Um ator representado como um retngulo de classe com o esteretipo "ator". O

cone padro do esteretipo para um diagrama de caso de uso a figura do "homem de
palitinhos" (figura 10), com o nome do ator abaixo da figura.
Dentro de um diagrama de caso de uso os relacionamentos so significantes. A UML

especifica os seguintes relacionamentos:
Comunicao. A participao de um ator em um caso de uso representado por uma

linha slida ligando o smbolo do ator ao smbolo do caso de uso. O ator
dito se "comunicar" com o caso de uso.
Extends. Um relacionamento extends entre casos de uso representado por um

seta de generalizao do caso de uso provedor da extenso para o caso
de uso base. A seta rotulada com o esteretipo <<extends>>. Um
relacionamento desse tipo, de um caso de uso A para um caso de uso B,
indica que uma instncia do caso de uso B pode incluir o
comportamento especificado por A .
Uses. Um relacionamento do tipo uses entre casos de uso representado por

uma seta de generalizao do caso de uso que est fazendo uso para o
caso de uso que est sendo usado. A seta rotulada com o esteretipo
<< uses >>. Um relacionamento desse tipo de um caso de uso A para um
caso de uso B indica que um instancia do caso de uso A ir usar o
comportamento especificado por B.
A especificao do comportamento externo de um caso de uso define as possveis

seqncias de mensagens trocadas entre os atores e o sistema. No nvel de caso de uso, elas
podem ser especificadas como uma mquina de estados finitos (incluindo um diagrama de
atividades) na qual as transies so rotuladas por trocas de mensagens. Um tipo de caso de
uso pode ser instanciado como uma instncia de caso de uso. Normalmente, pelo menos um
cenrio deve ser preparado para cada tipo de instncia significativa diferente de um caso de
uso. Cada cenrio mostra a seqncia de interaes entre os atores e o sistema, com todas as
definies definidas.
Gerao de Arquivo
de Ref. Bibliogrficas Criao de
<<uses>> Sinnimos
Manuteno de <<uses>>
Sinnimos Excluso de
<<uses>> Sinnimos
Pesquisador
Manuteno de Itens
Alterao de
Bibliogrficos <<uses>> Sinnimos
<<uses>> <<uses>>
Alterao de Itens <<uses>>
Bibliogrficos
Insero de Itens
Bibliogrficos Excluso de Itens
Bibliogrficos
<<uses>>
<<uses>>
Figura 19 Diagrama de Casos de uso parcial do SAPES
4.5. Diagramas de Seqncia

Um diagrama de seqncia mostra uma interao arranjada em uma seqncia de
tempo. Em particular, ele mostra os objetos participando na interao pelas suas "linhas de
vida" e as mensagens que eles trocam, arranjadas em uma seqncia de tempo. Ele no mostra
a associao entre objetos.
Diagramas de seqncia e de colaborao expressam informaes similares mas fazem

isso de formas diferentes. Diagramas de seqncia mostram a seqncia explcita de mensagens
e so melhores para especificaes em tempo real e para cenrios complexos. Diagramas de
colaborao mostram os relacionamentos entre objetos e so melhores para entender todos os
efeitos sobre um dado objeto e para projeto procedimental.
Um diagrama de seqncia tem duas dimenses: a vertical que representa o tempo e a

horizontal, que representa os diferentes objetos.
Um objeto mostrado com uma linha pontilhada vertical chamada de "linha da vida". A
linha da vida representa a existncia do objeto em um tempo determinado. Se o objeto criado
ou destrudo durante o perodo de tempo mostrado no diagrama, ento a linha da vida comea
e pra no ponto apropriado; caso contrrio ela vai desde o incio at o fim do diagrama. Um
smbolo de objeto desenhado no topo da linha da vida; se o objeto criado durante o

diagrama, ento a mensagem que o cria desenhada com a ponta da seta para o smbolo de
objeto. Se o objeto destrudo durante o diagrama, ento sua destruio marcada por um
"X", ou na mensagem que causa a destruio ou na mensagem final retornada pelo objeto
destrudo.
Figura 20. Elementos de um Diagrama de Seqncia
Uma ativao mostra o perodo no tempo durante o qual o objeto est ativo, seja por
uma ao direta ou por um procedimento subordinado. representada como um fino
retngulo cujo topo alinhado com seu tempo de inicializao e cujo final alinhado com o
trmino da sua ativao.
Uma mensagem representada como uma seta horizontal da linha da vida de um objeto
para a linha da vida de outro objeto. A seta rotulada com o nome da mensagem (operao ou
sinal) e os valores dos seus argumentos.
Os diagramas de seqncia podem ser usados de duas formas: de forma genrica e

como uma instncia. A forma genrica descreve todas as possveis alternativas em um cenrio,
por exemplo, um cenrio genrico de abertura de uma conta bancria deveria descrever em um
diagrama de seqncia situaes como: uma abertura de conta bem sucedida, uma abertura de
conta no concedida por falta de crdito do cliente e uma abertura de conta com um depsito
imediato na conta. J um diagrama de seqncia instanciado deveria mostrar somente uma
destas possibilidades, ou seja, deveriam ser construdos trs diagramas de seqncia, um para
cada situao. Na Figura 21 mostrado um diagrama de seqncia genrico.
Figura 21 Diagrama de Seqncia genrico para a impresso de um arquivo
Os diagramas de seqncia ainda podem ser usados para mostrar a interao entre os
atores e o sistema, abstraindo o sistema como uma caixa preta, dessa forma as mensagens do
diagrama seriam os eventos externos disparados pelo ator e as respostas dados pelo sistema
pesq : : Sistema
Pesquisador
excluir_item_bibliogrfico(id_item)
mensagem6_emitida("Confirma a excluso do item bilbiogrfico")
confirmar_excluso(char)
mensagem5_emitida("Item bibliogrfico excludo")

aos eventos de externos. Um exemplo do evento excluir_item_bibliogrfico apresentado na

Figura 22.
Figura 22 Diagrama de Seqncia do SAPES Interao entre o ator Pesquisador e o

Sistema
4.7. Diagramas de Colaborao

Um diagrama de colaborao mostra uma interao organizada em torno dos objetos
na interao e os seus links de uns para outros. Diferentemente de um diagrama de seqncia,
um diagrama de colaborao mostra os relacionamentos entre objetos. Por outro lado, o
diagrama de colaborao no mostra o tempo como uma dimenso separada, ento a
seqncia de mensagens e os threads concorrentes devem ser determinados usando-se nmeros
em seqncia.
Os objetos interagem para realizar um certo propsito (como executar uma operao)
trocando mensagens. A troca de mensagens entre objetos para realizar um propsito especfico
chamada de uma "interao". Interaes so mostradas como diagramas de seqncia ou
como diagramas de colaborao. Ambos os formatos de diagramas mostram a execuo de
colaboraes. Diagramas de colaborao mostram o contexto completo de uma interao,
incluindo os objetos e seus relacionamentos relevantes para um interao particular, ento
freqentemente estes diagramas so melhores para propsitos de projeto.
Um diagrama de colaborao um grafo de objetos e ligaes com fluxo de mensagens

conectados as ligaes. O contexto do diagrama mostra os objetos relevantes para a
performance de uma operao, incluindo objetos afetados indiretamente ou acessados durante
a operao. Objetos criados durante a execuo podem ser designados como << new >>;
objetos destrudos durante a execuo podem ser designados como << destroyed >>; objetos
criados durante a execuo e ento destrudos podem ser designados como << transient >>.
Figura 23. Diagrama de colaborao
O invocador de uma interao deve ser mostrado no diagrama de colaborao como

um smbolo de ator. As mensagens que implementam uma operao so numeradas a partir do
1. Para um fluxo de controle procedimental os nmeros de mensagens subsequentes so
aninhados de acordo com o aninhamento de chamada. Para uma seqncia no procedimental
de troca de mensagens entre objetos concorrentes a seqncia de nmeros est no mesmo
nvel, isto , no aninhados.
A sintaxe de uma mensagem :
Nmero_seqncia {[condio-guarda] *[clusula_iterao]:

valor_retorno := }assinatura
Na qual os elementos entre {} so opcionais. O nmero_seqncia a ordem na qual a

mensagem ser executada. A condio guarda uma expresso booleana que deve ser
verdadeira para que o mtodo seja executado, ou seja, uma pr-condio. A
clusula_iterao indica uma execuo iterativa, por exemplo, uma mensagem 1.1
*[x=1..10] : faaAlgo(), a mensagem faaAlgo ser executada enquanto x tiver
valor entre 1 e 10. O valor_retorno representa a varivel que receber o valor retornado pela
mensagem e assinatura a chamada da mensagem(mtodo), com os seus devidos argumentos,
que se deseja executar.
Pesq :
pesquisador
1: excluir_item_bibliogrfico(id_item, char)
B: 3: procurar_item(id_item) itens : Item

Bibliografia bibliogrfico
6: excluir_IB(id_item)
2: create(
)
4: criar_mensagem12("Item bibliogrfico no encontrado")
5: criar_mensagem6("Confirma a excluso do item

bibliogrfico?",confirmao
)
7: criar_mensagem5("Item bibliogrfico excludo")
8: emitir_mensagem(mensagem)
mensagem :
Mensagem_vdeo
Figura 24 Diagrama de Colaborao do SAPES Excluir_item_bibliogrfico
possvel tambm enviar uma mesma mensagem para uma coleo de objetos
(multiobject) conforme mostrado na Figura 25.
Figura 25 Uma mensagem para um multiobject
4.8. Diagrama de Estado

Um diagrama de estado representa a seqncia de estados que um objeto ou uma interao
passa durante sua vida, em resposta a um estmulo recebido. Um diagrama de estado
representa o ciclo de vida de um objeto. Para isso ele mostra os estados que um objeto pode
ter e como os eventos afetam estes estados. Podem ser considerados eventos o recebimento de
uma mensagem, um tempo esgotado, um condio que se tornou verdadeira. O objeto emite
uma resposta a um estmulo(evento) recebido. Podem haver aes associadas s respostas.
Figura 26. Diagrama de Estado
A semntica e a notao descrita nesta seo so substancialmente as mesmas dos

statecharts de Harel.
Um diagrama de estado um grafo bipartido de estados e transies. Todo o diagrama

de estado conectado a uma classe ou um mtodo (uma implementao de operao).
Um estado uma condio durante a vida de um objeto ou uma interao durante a

qual ele satisfaz alguma condio, executa alguma ao, ou espera algum evento. Um objeto
mantm-se em um estado por um tempo finito (no-instantaneo).
Um estado representado como um retngulo com os cantos arredondados. Pode ter

um ou mais compartimentos. Os compartimentos so opcionais. So os seguintes:
compartimento do nome, de variveis de estado e de atividades internas (com uma lista de
aes ou atividades internas executadas enquanto o objeto est no estado).
Cada nome de evento pode aparecer no mximo uma vez em um nico estado.
As seguintes aes especiais tem a mesma forma da lista de atividades internas, mas
representam palavras reservadas que no podem ser usadas como nomes de eventos:
entry '/' action-expression Uma ao atmica executada na entrada do estado

exit '/' action-expression Uma ao atmica executada na sada do estado
do '/' action-expression Uma ao em andamento executada enquanto o estado

estiver ativo.
action-expressions podem usar variveis do estado corrente ou estados anexos,

atributos e links do objeto "proprietrio" do estado, e parmetros de transies de entrada (se
eles aparecem em todos os caminhos de entrada).
Um estado pode ser refinado em sub-estados concorrentes (Figura 27) usando

relacionamentos and, ou em sub-estados disjuntos mutuamente exclusivos (Figura 28) usando
relacionamentos or. Um dado estado pode ser refinado em apenas uma das duas formas. Estes
sub-estados podem ser novamente refinados, de uma forma ou de outra.
Figura 27. Sub-estados concorrentes
Figura 28. Sub-estados seqenciais
Para propsitos prticos no diagrama de estados, um evento uma ocorrncia que

pode disparar uma transio do estado. Eventos podem ser de muitos tipos: uma condio que
se torna verdadeira, a recepo de um sinal explcito de um objeto para outro, a recepo de
uma chamada para uma operao por um objeto, ou a passagem de um perodo de tempo
designado aps um determinado evento.
Uma transio simples um relacionamento entre dois estados, indicando que um

objeto no primeiro estado ir entrar em um segundo estado e executar certas aes
especificadas quando um evento especfico ocorrer. Quando ocorre essa mudana de estado
dizemos que a transio "disparou". O "disparador" de uma transio a ocorrncia de um

evento que est rotulando a transio.
Uma transio representada por uma seta slida de um estado para outro rotulada por
uma string de transio. A sintaxe do rtulo de uma transio :
nome_evento (parmetros_evento) [condio_guarda] /

expresso_ao ^clusula_envio
Na qual expresso_ao representa a ao que deve ser executada assim que o evento
for disparado. A clusula_envio representa um caso especial na transio, no qual deve-se
enviar uma mensagem a um objeto durante a transio entre os dois estados. Ela tem a
seguinte sintaxe: Objeto . nome_evento_do_objeto (parmetros).
Reservar_ttulo /
nmero_reserva ++
Reservar_ttulo /
nmero_reserva ++
No Reservado Reservado
Remover_reserva
[nmero_reserva=1 ] / Remover_reserva
nmero_reserva -- [nmero_reserva >1 ] /
nmero_reserva --
Figura 29 Diagrama de Estados para a classe Ttulo de uma biblioteca
4.9. Diagrama de Atividade

Um diagrama de atividade um caso especial de diagrama de estado no qual todos os
estados so estados de ao e no qual todas as transies so disparadas pela finalizao das
aes nos estados fontes. Todo o diagrama de atividade conectado (atravs do modelo) a
uma classe ou a implementao de uma operao ou a um caso de uso. O propsito deste
diagrama focalizar sobre o fluxo direcionado pelo processamento interno. Os diagramas de
atividade so usados em situaes onde todos ou a maioria dos eventos representam a
concluso das aes geradas internamente (isto , fluxo de controle procedimental). Os
diagramas de estado so usados em situaes onde eventos assncronos ocorrem.
4.9.1. Estado Ao
Um estado ao uma maneira rpida de descrever um estado com uma ao interna e
pelo menos uma transio de sada envolvendo o evento implcito que completa a ao interna.
Um estado ao no deve ter transies internas ou transies de sada baseadas em eventos
explcitos; use estados normais para esta situao. O uso normal de um estado ao para
modelar um passo na execuo de um algoritmo (um procedimento).
Um estado ao representado por duas linhas horizontais paralelas (abaixo e acima)

com arcos convexos nos dois lados. A expresso-ao colocada dentro deste smbolo. A
expresso-ao no precisa ser nica no diagrama.
Figura 30. Diagrama de atividade
Transies deixando um estado ao no devem apresentar uma assinatura de evento;

tais transies so implicitamente disparadas pelo trmino da ao no estado. As transies
podem incluir condies de guarda e aes.
4.9.2. Decises
Um diagrama de estado (e por derivao um diagrama de atividade) expressa decises
quando condies de guarda so usadas para indicar diferentes transies possveis que
dependem de uma condio booleana do objeto "dono" da transio.
Um esteretipo fornecido para uma deciso: a tradicional forma de diamante, com

uma ou mais transies de entrada e com uma ou mais transies de sada, cada uma rotulada
com uma condio de guarda distinta e sem disparadores de eventos.
Figura 31 Exemplo de Deciso em um diagrama de estado/atividade
4.9.3. Swinlanes
As aes podem ser organizadas em swinlanes (raias). Swinlanes so um tipo de
package para organizao de responsabilidades dentro de uma classe. Elas sempre
correspondem a unidades organizacionais em modelos de negcios.
Um diagrama de atividade pode ser dividido visualmente em swinlanes, cada uma

separada de suas swinlanes vizinhas por linhas verticais, em ambos os lados. Cada swinlane
representa responsabilidade por parte da atividade total, e pode ser eventualmente
implementada por um ou mais objetos. Cada ao atribuda a uma swinlane. Transies
podem atravessar as linhas. No h nenhuma representao semntica na ordem das swinlanes.
Figura 32. Swinlanes em um diagrama de atividade
4.10. Diagramas de Implementao

Diagramas de implementao mostram aspectos de implementao, incluindo estrutura
de cdigo fonte e estrutura de implementao em tempo de execuo. Eles aparecem em duas
formas: diagramas de componentes, que mostram a estrutura do cdigo em si e diagramas de
disponibilidade, que mostram a estrutura do sistema em tempo de execuo.
4.10.1. Diagramas de Componentes

Um diagrama de componentes mostra as dependncias entre componentes de software,
incluindo componentes de cdigo fonte, componentes de cdigo binrio, e componentes
executveis. Um mdulo de software pode ser representado como um tipo de componente.
Alguns componentes existem em tempo de compilao, alguns existem em tempo de linkagem,
e alguns existem em tempo de execuo; alguns existem mais de uma vez. Um componente
compile-only um componente que s tem significado em tempo de compilao; um
componente run-time, neste caso, seria um programa executvel.
Um diagrama de componente tem apenas uma forma "tipo", no uma forma "instncia".
Para mostrar instncias de componentes, usa-se um diagrama de disponibilidade.
Um diagrama de componente um grafo de componentes conectado por

relacionamentos de dependncia. Componentes tambm podem ser conectados a componentes
por um compartimento fsico representando relacionamentos de composio.
Um componente mostrado como um retngulo com uma pequena elipse e dois

retngulos menores projetando-se em um de seus lados. Uma instncia de componente tem um
nome e um tipo. O nome do componente e seu tipo pode ser mostrado como uma string
sublinhada, seja dentro do smbolo de componente, acima ou abaixo, com a sintaxe:
nome_componente: tipo_componente. Um esteretipo pode ser usado para indicar qual etapa
do ciclo de vida o componente descreve (fonte, binrio, executvel, ou mais que um destes).
Nas Figura 33 e 34 so apresentados exemplos de diagramas de componentes.
Um diagrama contendo tipos de componentes e tipos de ns pode ser usado para

mostrar dependncias do compilador, as quais so representadas por setas pontilhadas de um
componente cliente para um componente servidor ao qual o primeiro depende de alguma
forma. Os tipos de dependncias so especificas da linguagem e podem ser mostradas como
esteretipos de dependncia.
window handler main class
(whnd.cpp) (main.cpp)
window handler main class

(whnd.obj) (main.obj)
graphic lib client program

(graphic.dll) (client.exe)
Figura 33. Exemplo de Diagrama de componente

<<page>>
home.html
<<file>> <<document>>
animlogo.java animlogo.doc
<<file>> <<document>>
animator.java animator.doc
Figura 34. Exemplo de Diagrama de componente
4.10.2. Diagramas de Disponibilidade

Diagramas de disponibilidade mostram a arquitetura em tempo, em tempo de execuo,
dos processadores, dispositivos e componentes de software que executam nesta arquitetura, ou
seja, envolvem a topologia do sistema, descrevendo a estrutura de hardware e software.
Instncias de componentes de software representam manifestaes em tempo de execuo de
unidades de cdigo. Componentes que no existem em tempo de execuo no aparecem
nestes diagramas; devem ser mostrados no diagrama de componente.
Um diagrama de disponibilidade um grafo de ns conectados por associaes de

Pentium
comunicao. Um "n" um objeto 466
fsico PC doum
que representa Bob:recurso computacional, ele inclui
MMX Pentium
geralmente computadores com processadores, e dispositivos, como impressoras, leitoras de
466 MMX
carto, dispositivos de comunicao, etc., como mostrado na Figura 34. Ns podem ser
<<printer>> <<router>>
HP LaserJet Cisco Router
5MP X2000
representados como tipos e como instncias. Podem residir sobre instncias de ns tanto
instncias de objetos como de componentes.
Figura 34 Exemplos de Ns
Um n representado como uma figura que se parece com uma viso tridimensional de
um cubo. Uma instncia de um n tem um nome e um tipo. O n pode ter uma string de nome
sublinhada dentro ou abaixo dele, seguindo a seguinte sintaxe: nome : tipo. O nome o nome
do n e o tipo se refere ao tipo deste n. Ambos so opcionais.
Ns podem conter instncias de componentes; isto indica que o componente vive ou

executa sobre o n. Componentes podem conter objetos; isto indica que o objeto parte do
componente. Os componentes so conectados a outros componentes por setas pontilhadas de
dependncia. Isto indica que um componente pode usar os servios de outro componente; um
esteretipo pode ser usado para indicar a dependncia precisa, se necessrio.
O diagrama de disponibilidade tambm pode ser usado para mostrar quais componentes
podem executar sobre quais ns, usando setas pontilhadas com o esteretipo <<suport>>.
Figura 35. Uso de ns contendo objetos
Setas pontilhadas de dependncia mostram a capacidade de um tipo de n para

suportar um tipo de componente. Um esteretipo pode ser usado para especificar o tipo
preciso de dependncia.
Instncias de componentes e objetos podem estar contidas dentro de smbolos de

instncia de n. Isto indica que os itens residem nas instncias dos ns.
Um tipo componente representa um pedao do cdigo do software (fonte, binrio, ou

executvel) e pode ser usado para mostrar dependncias de compilador e de execuo. Uma
instncia de componente representa uma unidade de cdigo em tempo de execuo e pode ser
usada para mostrar unidades de cdigo que tem identidade em tempo de execuo, incluindo
suas localizaes nos ns. Apenas componentes executveis podem ser alocados em ns.
Figura 36 Diagrama de Disponibilidade
5. Concluso
No desenvolvimento das abordagens orientadas a objetos, a unificao das
metodologias existentes pareceu um caminho natural, visto que os mtodos j estavam
evoluindo um para o outro independentemente. Neste contexto, no fazia sentido continuar
evoluindo separadamente, pois isto traria a oportunidade para o surgimento de diferenas
desnecessrias e gratuitas. Baseados neste fato os autores da UML decidiram por fundir as
melhores prticas disponveis na orientao a objetos de forma a especificar uma linguagem de
modelagem simples, clara e expressiva.
Desta forma, foi criado um conjunto de documentos especificando a UML, contando

com a apoio de um consrcio formado por grandes empresas chamado UML Partners. A
ltima verso destes documentos foi liberada em setembro de 1998, e trata-se da verso 1.1.
A UML visa criar um padro de notao com forte semntica para a especificao de
sistemas complexos. Ela no especifica um padro de processo propositadamente, baseada no
fato de que cada organizao e cada projeto se enquadram em diferentes tipos de processos.
Existem ferramentas que suportam a UML, como a Rational Rose, da Rational

Software Corporation, e a tendncia que este mercado cresa cada vez mais, j que espera-se
que a UML seja adotada como um padro para modelagem de sistemas.
6. Referncias Bibliogrficas
[Rat97-a] Rational, 1997, UML Summary, verso 1.0.1, 19 de maro de 1997, disponivel
atravs de http://www.rational.com
[Rat97-b] Rational, 1997, UML Semantics, verso 1.0, 13 de janeiro de 1997, disponvel
[Rat97-c] Rational, 1997, UML Semantics, verso 1.1, 1 de setembro de 1997, disponvel
[Rat97-d] Rational, 1997, UML Notation Guide, verso 1.0, 13 de janeiro de 1997, disponivel
[Hen97] Henderson-Sellers, B., Firesmith, D. C., Evaluating Third Generation OO Software

Development Approches, 27 de junho de 1997, disponvel atravs de
http://www.csse.swin.edu.au/cotar/OPEN
[ERI97] ERICKSSON, H., PENKER, M., UML Toolkit, John Wiley & Sons, USA, 1997.
[RUM93] RUMBAUGH, J. et al., Modelagem e Projetos Baseados em Objetos, Editora

Campus,1993.
[MAR93] MARTIN, J., Princpios de Anlise e Projeto Baseados em Objetos, Editora

Campus, 1993.
ANEXO A
DOCUMENTO DE REQUISITOS DO
SAPES
Viso Geral do Sistema
O Sistema de Apoio Escrita (SAPES) tem como objetivo principal auxiliar a pesquisa
bibliogrfica. Os usurios deste sistema so, principalmente, pesquisadores que durante a sua
pesquisa bibliogrfica podem ler publicaes (por exemplo: artigos, livros e peridicos) e
armazen-las no sistema atravs de itens bibliogrficos, construindo, assim, a sua bibliografia
pessoal. Esta bibliografia pode ser alterada e consultada conforme a necessidade do
pesquisador, alm da possibilidade de fornecer diferentes tipos de relatrio. O pesquisador
pode tambm utilizar o sistema durante a redao de textos cientficos. Atravs do documento
produzido pelo pesquisador, o sistema reconhece as citaes e gera automaticamente a
referncia bibliogrfica.
Requisitos Funcionais
Preparao e Manuteno dos Itens Bibliogrficos

1. O sistema deve permitir a insero, alterao e excluso de itens bibliogrficos, mantendo
uma bibliografia.
2. O sistema deve solicitar ao pesquisador os itens de informao necessrios para inserir um
item bibliogrfico na bibliografia. Os itens de informao so: ttulo, autor(es),
data(ms/ano), local, resumo da publicao, assunto, numerao fsica, editora, peridico
(volume, nmero, pginas), congresso e forma de citao.
3. O sistema deve fornecer mensagens de erro quando itens bibliogrficos incompletos forem
inseridos. Tais mensagens interrogam o pesquisador se deseja cancelar a operao de
insero, completar as informaes incompletas ou concluir a insero assim mesmo.
4. O sistema deve, no caso de ocorrer a tentativa de insero de um item bibliogrfico j
existente, comunicar ao pesquisador a existncia deste item bibliogrfico na bibliografia.
Se, neste caso, o pesquisador confirmar a operao de insero, o sistema deve informar
que tal operao ir alterar o item bibliogrfico existente.
5. O sistema deve gerar automaticamente a forma de citao (cdigo de citao) seguindo o
padro ABNT (Associao Brasileira de Normas Tcnicas) quando o pesquisador inserir
um item bibliogrfico na bibliografia.
6. O sistema deve fornecer facilidades para a criao e manuteno de uma lista de
sinnimos, para os seguintes itens de informao de um item bibliogrfico da
Bibliografia: autor, editora, peridico e congresso.
7. O sistema deve permitir a alterao dos itens de informao de um item bibliogrfico da
bibliografia, com exceo do cdigo de citao que gerado automaticamente pelo
sistema. O pesquisador pode acessar/recuperar um item bibliogrfico pelos itens de
informao: autor, ttulo e pelos sinnimos de autor e ttulo, respectivamente.
8. O sistema deve permitir a excluso de um item bibliogrfico se este item existe na
bibliografia. O pesquisador pode acessar/recuperar um item bibliogrfico a ser excludo
pelos itens de informao: autor, ttulo e pelos sinnimos de autor e ttulo,
respectivamente.
9. O sistema deve permitir a insero de itens bibliogrficos importados de bibliografias de
outros pesquisadores, atravs dos itens de informao autor e ttulo e tambm pelos
sinnimos de autor e ttulo, respectivamente. O operao de insero pode exigir ou no
confirmao. A importao de itens pode ser total (todo a bibliografia do pesquisador) ou
parcial (somente alguns itens bibliogrficos).
10. O sistema no deve permitir a alterao da bibliografia por parte de pesquisadores no
autorizados (Segurana de Acesso).
Consultas Gerais e Emisso de Relatrios

11. O sistema deve permitir consulta a itens bibliogrficos existentes na bibliografia. A busca
destes itens bibliogrficos pode ser realizada a partir dos seguintes itens de informao ou
combinao destes: autor, assunto, editora, peridico, local e ano de publicao. Assim, o
sistema apresenta para o pesquisador todos o(s) item(s) bibliogrficos que satisfazem o
critrio de busca.
12. O sistema deve, durante o processo de consulta, averiguar com o pesquisador quais itens
de informao ele deseja recuperar. Assim, o sistema pode recuperar itens bibliogrficos
totais ou parciais.
13. O sistema deve solicitar ao pesquisador, no momento da consulta o tipo do relatrio a ser
gerado. O relatrio contm itens de informao relativos aos itens bibliogrficos
selecionados pelo pesquisador durante o processo de consulta. Os relatrios podem ser
impressos (na tela ou na impressora) ou podem ser gravados em arquivos para posterior
anlise.
14. O sistema deve ordenar os itens bibliogrficos dos relatrios de acordo com a preferncia
do pesquisador, utilizando as alternativas pelos itens de informao: autor, ttulo e pelos
sinnimos de autor e ttulo, respectivamente.
15. O sistema deve fornecer recursos para a criao e impresso de fichas tcnicas a partir das
informaes que o sistema possui sobre os itens bibliogrficos. Uma vez geradas as fichas
tcnicas, o pesquisador pode optar por relatrio impresso ou gravao em arquivos. As
fichas tcnicas contm alm dos itens de informao do item bibliogrfico, de forma
parcial ou total, anotaes do pesquisador a respeito do item bibliogrfico.
Uso dos Itens Bibliogrficos durante a redao de um texto cientfico
16. O sistema deve percorrer o documento produzido pelo pesquisador a fim de identificar
todas as citaes encontradas. A partir destas citaes o sistema deve gerar
automaticamente a referncia bibliogrfica seguindo o padro ABNT, e que
posteriormente ser anexada ao documento. As citaes no documento devem estar na
forma ABNT.
17. O sistema deve permitir ao pesquisador ordenar as referncias das referncias
bibliogrficas em ordem alfabtica por autor ou pela ocorrncia da sua respectiva citao
no documento.
18. Caso o sistema encontre uma citao no documento que no esteja na bibliografia, o
sistema dever fornecer uma mensagem adequada ao pesquisador alertando a ocorrncia
de uma possvel citao incorreta.
19. O sistema no deve permitir que o pesquisador altere as informaes geradas
automaticamente pelo sistema. Caso o pesquisador deseje alterar os itens de informao
de uma referncia das referncias bibliogrficas por erro ou por no estar completa, ou
deseje inserir um item bibliogrfico no encontrado pelo sistema, este deve proceder com
as alteraes desejadas na bibliografia e em seguida o sistema deve percorrer novamente o
documento gerando uma nova bibliografia. Caso no deseje fazer alteraes na
bibliografia, dever ento fazer correes diretamente no documento.
Requisitos de Qualidade
Confiabilidade
20. O sistema deve ter capacidade para recuperar os dados perdidos da ltima operao que
realizou em caso de falha.
21. O sistema deve fornecer facilidades para a realizao de backups dos arquivos do sistema.
Eficincia
22. O tempo de processamento de uma operao de consulta no deve exceder trs segundos
para uma quantidade inferior a 10 itens bibliogrficos.
23. O tempo de resposta para as operaes de insero, alterao e excluso no deve exceder
a trs segundos.
Portabilidade
24. O sistema deve rodar em microcomputadores da linha IBM PC que possuam
microprocessador 486 DX ou superior, memria RAM mnima de 8Mbytes e rodam sob
Windows95.
25. O sistema deve ser facilmente portvel para o UNIX.

Apostila Curso Oo

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Apostila Curso Oo

Încărcat de

Drepturi de autor:

Formate disponibile

Projeto Orientado a Objetos - UML

Thelma Elita Colanzi

1.1 Histria da Abordagem OO

1.2 Conceitos Bsicos do Paradigma Orientado a Objetos

uma matriz ou um valor exclusivo de um atributo. As referncias dos objetos so uniformes e

Os procedimentos contidos nos objetos ganham um novo nome - mtodos. Os objetos

Os objetos com a mesma estrutura de dados(atributos) e o mesmo comportamento

Figura 1 Exemplos de Classes e Objetos

O Polimorfismo geralmente representa a qualidade ou estado de um objeto ser capaz

Class S1: Class S2: Class S3:

Figura 2 - Exemplo das Relaes de Herana e Herana Mltipla

O comportamento de uma classe especificado e utilizado nos mtodos associados s

Encapsulamento de dados uma tcnica empregada para garantir o ocultamento de

No projeto de sistemas a abstrao permite concentrar-se somente no que um objeto

1.3 Mtodos Orientados a Objetos

Os mtodos envolvem atividades a serem realizadas em cada fase do ciclo de vida do

A UML, a Unified Modelling Language, consiste de um metamodelo e uma notao,

dos componentes de um sistema, especialmente aqueles fortemente ligados a software. Seu

2.1 Histrico da UML

O desenvolvimento da UML comeou em outubro de 1994, quando Grady Booch e Jim

Booch, Rumbaugh e Jacobson foram motivados a criar uma linguagem de modelagem

Os esforos de Booch, Rumbaugh e Jacobson resultaram na verso 0.9 e 0.91 dos

Nos documentos da UML 1.0, disponveis via world wide web

2.2. O Escopo da UML

Primeiramente, a UML funde os conceitos dos mtodos Booch, OMT e OOSE. O

Segundo, os autores da UML objetivaram, em particular, a modelagem de sistemas

Terceiro, a UML focaliza uma linguagem de modelagem padro, no um processo

2.3. Novas Caractersticas da UML

Diversos conceitos novos foram includos[Rat97-a]:

3. O Conjunto de Documentos UML

3.1. UML Summary

3.2. UML Semantics

Um metamodelo uma linguagem para especificar um modelo, neste caso, um modelo

3.3. UML Notation Guide

3.4. UML Process Extensions

4.1. Organizao do Documento

Semntica Breve resumo da semntica. Para maiores explicaes

Notao Explica os elementos notacionais da caracterstica.

Opes de Apresentao Descreve vrias maneiras de apresentar a informao no

Guidelines de Estilo Sugestes para o uso de marcas estilizadas, tais como

4.2 Notao Genrica

Figura 2. Exemplo de Nota

Para um nico smbolo grfico (como uma classe ou um caminho de associao) a

MathPak :: Matrices :: BandedMatrix.dimension

4.2.6. Property String

Uma property string mostrada como uma seqncia de property specifications

Uma property specification tem a forma: palavra_chave = valor, onde

Se a propriedade tem valor booleano, seu default verdadeiro, caso no seja

Exemplo de property string:

{ author=Joe Smith, deadline=31/03/1997, status=analysis }

Exemplos de tagged value:

A apresentao geral de um esteretipo o nome do esteretipo colocado entre os

Um esteretipo pode ser aplicado a classes, relacionamentos de dependncia (como um

Figura 4. Vrias notaes de esteretipos

4.3. Diagramas de Estrutura Esttica

4.3.1. Diagrama de Classe

4.3.2. Diagrama de Objetos

Figura 5 - Diagrama de Classes mostrando as classes e um Diagrama de Objetos com

Nome da Classe Nome da Classe

Figura 6 Notao de Classes e Associaes

Um atributo mostrado como uma string textual. A sintaxe padro :

visibilidade nome : tipo = valor_inicial { property string }

Figura 7 Exemplo de atributos da classe Fatura

visibilidade nome (lista_parmetros) : tipo_retorno { property string }