Analise e Projeto Orientado a Objetos

Prévia do material em texto

1 
 
 
 
 
 
 
 
 
 
 
Análise e Projeto 
Orientados a Objeto 
 
 
 
 
 
 
 
Autor: 
Haline Gregório Vicente 
 2 
 
 
 
Apostila de Análise e Projeto Orientados a Objeto 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
EmentaEmentaEmentaEmenta 
 3 
 
1. Introdução 
 
2. Conceitos 
 Objeto 
 Tipo de Objeto 
 Métodos 
 Encapsulamento 
 Classe 
 Herança 
 
3. Modelos Orientados Objeto 
 Modelos da Realidade 
 Ferramentas 
 Engenharia da Informação 
 
4. Análise da Estrutura do Objeto 
 Objetos e Tipos de Objeto 
 Associações de Objetos 
 Hierarquias de Generalização e Composição 
 Diagramas de Objeto-Relacionamento 
 Esquemas de Objetos 
 
5. Banco de Dados Orientados a Objeto 
 O Banco de Dados Relacional 
 Banco de Dados Ativos 
 Desempenho 
 Diferenças entre BDR e BDOO 
 
6. Funções 
 Funções Inversas 
 Restrições à Cardinalidade 
 Tipos de atributos convencionais 
 Expressão da Função 
 
 7. Diagramas de Fluxos de Objeto 
 7.1. A Função de um Projeto 
 7.2.Diagramas de Fluxos de Dados 
 7.3. Diagramas de Fluxos de Objetos 
 7.4.Nivelamento 
 
 
 
História 
 4 
 
Antes dos Anos 70 
 
� Técnicas de Documentação de Programas 
� Fluxogramas 
� HIPO (Hierarchy plus Input Process Output-produto IBM) 
� Outras técnicas 
� (excesso de diagramas) 
Meio dos Anos 70 
 
� Análise Estruturada - Tom de Marco, Yourdon, Gane. 
� Projeto Estruturado - Constantine, Myers, Yourdon, Page-Jones 
 
Anos 80 
 
� Modelagem de Informações 
� Modelagem Essencial 
� Sistemas de Tempo Real 
� Ferramentas CASE (Computer Aided Software Engineering) 
 
Anos 90 
 
� Análise e Projeto Orientados a Objetos 
� Coad 
� Booch 
� Rambaugh (OMT) 
� Jacobson 
� Coleman (FUSION) 
� UML 
 
 
 5 
 
Anos 2000... 
 
• WEB 
• Componentes 
• Frameworks 
• eXtreme Programming (XP) 
• Orientação a Aspectos (AOP) 
• Processos Ágeis 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1. Introdução 
 6 
 
 As técnicas orientadas a objeto permitem que o software seja construído de 
objetos que tenham um comportamento especifico. Os próprios objetos podem ser 
construídos a partir de outros, os quais, por sua vez, podem ainda ser construídos de 
outros. 
 A análise de sistemas no mundo orientado a objeto é feita analisando-se os objetos 
e os eventos que interagem com esses objetos. O projeto de software é feito reusando-se 
classes de objetos existentes e quando necessário, construindo-se novas classes. 
 Técnicas orientadas a objeto podem ser usadas para simplificar o projeto de 
sistemas complexos. O sistema pode ser visualizado como uma coleção de objetos, 
estando cada um dos objetos em um determinado estado. Os objetos são construídos a 
partir de outros objetos. 
 As técnicas orientadas a objeto tornam-se muito poderosas quando combinadas a 
outras tecnologias (CASE e I-CASE Programação Visual, Geradores de Código, 
Repositório, Engenharia de Informação, entre outros). 
 A análise e o projeto orientados a objeto modelam o mundo em termos de objetos 
que tem propriedades e comportamentos e eventos que disparam operações que mudam o 
estado dos objetos. Os objetos interagem com outros objetos. 
 A modelagem e o projeto orientados a objeto são os paradigmas que devem 
integrar todas as ferramentas e técnicas poderosas para a criação de software. Estratégia 
de desenvolvimento baseada no conceito de que o sistema deve ser construído a partir de 
componentes reutilizáveis, chamados de objetos. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2.Conceitos 
 7 
Entre as idéias fundamentais básicas para a tecnologia orientada a objeto incluem-se: 
• Objetos; 
• Classes; 
• Métodos; 
• Herança; 
• Encapsulamento. 
Cada conceito é uma idéia ou um entendimento pessoal que temos do nosso mundo. 
Os conceitos que adquirimos nos permitem dar sentido sobre as coisas do nosso mundo. Essas 
coisas às quais nossos conceitos se aplicam são denominados objetos. 
 
ObjetoObjetoObjetoObjeto 
 
� Um objeto pode ser real ou abstrato. 
� Os objetos possuem informações (contém dados) e desempenham ações (possuem 
funcionalidade). 
� Qualquer coisa à qual um conceito ou tipo de objeto se aplica – uma instância de 
um conceito ou tipo de objeto. 
� Um objeto é uma instância de uma classe. 
 
Exemplo: 
 
• Uma fatura; 
• Uma organização; 
• Um vôo de avião; 
• Uma pessoa; 
• Um lugar. 
Na análise e no projeto OO, estamos interessados no comportamento do objeto. As 
operações são codificadas como métodos. A representação de software OO do objeto é, 
dessa forma, uma coleção de tipos de dados e métodos. No software OO: Um objeto é 
qualquer coisa, real ou abstrata, a respeito da qual armazenamos dados e os 
métodos que os manipulam. 
 
 
Um tipo de objeto é uma categoria de objeto. (entidade) 
Um objeto é uma instância de um tipo de objeto. (atributo) 
 
 
 8 
Exemplo: um tipo de objeto poderia ser Fatura e um objeto poderia ser nº. 51.783. 
 
OBS: O termo objeto, porém, é diferente do termo entidade. A entidade preocupa-se apenas 
com os dados enquanto o objeto preocupa-se tanto com os dados como com os métodos com os 
quais os dados são manipulados. 
 
MétodosMétodosMétodosMétodos 
 
� Os métodos especificam a maneira pela qual os dados de um objeto são 
manipulados. 
� Uma especificação dos passos pelos quais uma operação deve ser executada. 
� Ele é um script de implementação de uma operação. 
� Diferentes métodos podem ser usados para executar a mesma operação. 
� Os métodos de um tipo de objeto referenciam somente as estruturas de dados 
desse tipo de objeto. 
� A ação que um objeto ou uma classe podem desempenhar. 
� Os métodos são similares às funções e procedures do universo da programação 
estruturada. 
 
Um objeto é, dessa forma, uma coisa, com suas propriedades representadas pelos 
tipos de dados e seu comportamento representado pelos métodos. 
 
EncapsulamentoEncapsulamentoEncapsulamentoEncapsulamento 
 
 O ato de empacotar ao mesmo tempo dados e objetos é denominado encapsulamento. O 
objeto esconde seus dados de outros objetos e permite que os dados sejam acessados por 
intermédio de seus próprios métodos. Isso é chamado de ocultação de informações 
(information hiding). 
 
 
� O encapsulamento protege os dados do objeto do uso arbitrário e não-intencional. 
� Encapsulamento é o resultado (ou ato) de ocultar do usuário os detalhes da 
implementação de um objeto. 
� O Encapsulamento é importante porque separa a maneira como um objeto se 
comporta da maneira como ele é implementado. 
� A definição de como implementar os conhecimentos ou ações de uma classe, sem 
informar como isto é feito. 
 9 
 
Exemplo: 
 
 
 
 Cada objeto encapsula uma estrutura de dados e métodos. Uma estrutura de dados 
encontra-se no centro de um objeto. O objeto é manipulado por métodos que implementam as 
operações permitidas. A estrutura de dados pode ser usada somente com os métodos. Essa 
restrição ao acesso é denominada encapsulamento, que protege os dados contra adulteração. Os 
dados do objeto não podem ser usados, exceto com esses métodos. 
 
 
ClasseClasseClasseClasse 
 
 O termo classe refere-se à implementação de software de um tipo de objeto. Um tipo de 
objeto especifica uma família de objetos sem estipular como o tipo e o objeto são 
implementados. Os tipos de objetos são especificados durante a análise OO. Os tipos de 
objetos são implementados como módulos enquanto na linguagem orientada a objeto, os tipos 
de objetos são classificados como classes. 
 
� Uma classe é uma implementação de um tipo de objeto. 
� Uma classe especifica uma estrutura de dados e os métodos operacionais 
permissíveis que se aplicam a cada um de seus objetos. 
� Uma classe pode ter sua própria estrutura de dados e métodos, bem como herda - 
lá de sua superclasse. 
 
Exemplo: Classe- Objeto - Método - Atributo.X+Y=XY 
abc 
Estrutura Encapsulada de Dados 
Operações permissíveis - a única 
maneira de manipular a estrutura de 
dados. O método da operação está 
oculto do usuário. 
Objeto 
 10 
 
 
Classes Abstratas e Concretas 
 
 A classe abstrata é uma classe que não possui objetos instanciados a partir dela, 
enquanto a classe concreta possui objetos instanciados (criados) a partir dela. 
 
 
Exemplo: No mundo real, por exemplo, existem automóveis e aviões, mas nada que seja 
simplesmente um veiculo (em outras palavras, se não for um carro ou avião, não é de nosso 
interesse). Isso significa que podemos instanciar objetos como carros e aviões, mas nunca 
iremos criar objetos veículos. As classes abstratas são criadas quando necessitamos de uma 
classe que implemente recursos comuns a duas ou mais classes. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Pessoa
Nome
Endereço
Telefone
Idade
Altura
Registrar()
Matricular()
Pagar()
Estudar()
Cadastrar()
Classe 
 
A 
T 
R 
I 
B 
U 
T 
O 
S 
M 
É 
T 
O 
D 
O 
S 
Pedro
Maria
Objetos 
Veículo 
Avião Carro 
Avião – nº. de motores, autonomia, 
velocidade máxima, altitude máxima, nº. 
passageiros (arremeter, aterrissar, glissar, 
aumentar e diminuir a velocidade). 
Carro - nº. passageiros, autonomia, marca, 
modelo (fazer curvas, aumentar e diminuir a 
velocidade). 
Veículo - nº. passageiros, autonomia 
(aumentar e diminuir a velocidade). 
 
 11 
HerançaHerançaHerançaHerança 
 
 
É comum haver similaridades entre diferentes classes. Frequentemente, duas ou mais 
classes irão compartilhar os mesmos atributos e/ou métodos. Como nenhum de nós deseja 
reescrever várias vezes o mesmo código, seria interessante se algum mecanismo pudesse tirar 
proveito dessas similaridades. A herança é esse mecanismo. Por intermédio da herança, é 
possível modelar relacionamentos do tipo “é” ou “é semelhante”, o que nos permite reutilizar 
rotinas e dados já existentes. 
 Uma subclasse herda as propriedades de sua classe-mãe; uma subclasse herda as 
propriedades das subclasses e assim por diante. Uma subclasse pode herdar a estrutura de 
dados e os métodos, ou alguns dos métodos, de sua superclasse. Ela também tem métodos e às 
vezes, tipos de dados próprios. 
 
 
 
 Herança – permite tirar proveito das similaridades entre as classes representadas por 
relacionamentos do tipo “é” ou “é semelhante”. 
 
 
 
 
 Subclasse – uma classe que é um subtipo de uma ou mais classes (denominadas 
superclasses). Como tal, ela herda todas as características de suas superclasses. Em outras 
palavras, todas as características de uma classe são reusáveis por suas subclasses. Se a classe B 
herda de A, então dizemos que B é uma subclasse de A. 
 
 Superclasse – Uma classe que é um supertipo de uma ou mais classes (tb chamadas de 
subclasses). Como tal, ela é uma classe a partir da qual todas as suas características são 
herdadas por suas subclasses. Em outras palavras, todas as características de uma superclasse 
são reusáveis por aquelas classes que são seus subtipos. Se a classe B herda de A, então 
dizemos que A é uma superclasse de B. 
 
 
Exemplo 1: A figura abaixo mostra uma classe e uma subclasse. A subclasse tem os mesmos 
métodos de sua superclasse, mas tem tb o método G. Ás vezes, uma classe herda propriedades 
de mais de uma superclasse. Isso é denominado herança múltipla. 
 
 
 12 
 
 
Exemplo 2: Pessoa – professor – aluno 
 
 
 
 
OBS: As subclasses deverão sempre ficar abaixo da superclasse e o semicírculo deverá sempre 
apontar da subclasse para a superclasse. 
 
 
Pessoa 
Professor 
Aluno 
A 
D 
H 
D A 
H G 
Classe 
Herança 
Subclasse 
 13 
Herança Simples e MúltiplaHerança Simples e MúltiplaHerança Simples e MúltiplaHerança Simples e Múltipla 
 
Quando uma classe herda características somente de uma outra classe, dizemos que esta é uma 
herança simples. Quando uma classe herda de duas ou mais classes, temos um caso de herança 
múltipla. Em qualquer circunstância, o fato que você deverá lembrar é o seguinte: a subclasse 
herda todos os atributos e métodos das superclasses. 
 
 
Hierarquias de GeneralizaçãoHierarquias de GeneralizaçãoHierarquias de GeneralizaçãoHierarquias de Generalização 
 
 Um conjunto de classes relacionadas por meio da herança. Uma boa maneira de 
organizarmos os conhecimentos é arranjando-o em hierarquias do geral para o mais especifico. 
Por exemplo, a figura abaixo descreve uma hierarquia com o conhecimento do tipo de objeto 
Pessoa no topo. Isso significa que Pessoa é um tipo de objeto mais geral do que empregado e 
estudante. Isso significa que empregado e estudante são subtipos de pessoa, ou, inversamente, 
que pessoa é um supertipo de empregado e estudante. 
 
 Pessoa 
 
 
 
 Empregado Estudante 
 
 
Vendedor Gerente 
 
Pássaro Lagarto 
Dragão 
Pássaro – Envergadura de assas, Velocidade 
máxima (comer/voar). 
Lagarto – Nº de garras, cor das escamas 
(comer/voar) 
Dragão – Nome, Envergadura de assas, 
Velocidade máxima, Nº. de garras, cor das 
escamas (expelir/capturar donzelas/comer) 
 14 
Diferenças entre análise e projeto: 
Primeira alternativa: 
1. A análise modela o problema e consiste das atividades necessárias para entender o 
domínio do problema (o que deve ser feito). É uma atividade de investigação. 
2. O projeto modela a solução e consiste das atividades de criação (como pode ser 
feito) 
 
Segunda alternativa: 
1. A análise consiste de todas as atividades feitas com ou para o conhecimento do 
cliente. A informação produzida é aquela que o cliente deve discutir e aprovar 
2. O projeto inclui as atividades que resultam em informação que interessa apenas ao 
programador 
3. Com essa definição, a análise invade um pouco o "lado da solução", pois o cliente 
deve discutir alguns tipos de interações que ocorrerão na interface do usuário, etc. 
 
 15 
 
Diagramas de ObjetoDiagramas de ObjetoDiagramas de ObjetoDiagramas de Objeto----RelacionamentoRelacionamentoRelacionamentoRelacionamento 
 Os tipos de objetos têm relação com outros tipos de objeto. Os diagramas de 
entidade-relacionamento são usados há anos na análise convencional de sistemas. 
Os diagramas mostram as associações entre tipos de entidades. Um diagrama de 
objeto-relacionamento é representado da mesma maneira que o diagrama de 
entidade relacionamento. 
 Veja a figura abaixo: 
 Um diagrama de objeto-relacionamento é essencialmente o mesmo que um 
diagrama de entidade-relacionamento, onde cada retângulo poderia ser um tipo de 
objeto na analise e projeto orientado a objeto. Fica mais fácil o entendimento do 
modelo quando os tipos de objetos e as relações são representados num diagrama 
de objeto-relacionamento; supertipos e subtipos num diagrama de generalização. 
 
 
 
 
Cliente Pedido 
Linha de 
Pedido 
Produto 
Estoque de 
Produto Armazém 
 16 
Diagramas Orientados a Objeto 
Resumo dos símbolos usados para a analise e projeto orientado a objeto. Como 
já sabemos um objeto, como uma entidade, é uma coisa real ou abstrata. Nós, por 
conseguinte, usamos um retângulo para desenhar tipos de objetos. Recomenda-se 
que os tipos de objetos e classes sejam desenhados com caixas de cantos vivos e as 
atividades com caixas de cantos arredondados. 
Dados 
Caixa de cantos vivos 
Representam dados (tipo 
De entidade, subtipos,registros) 
 
 
 
 
Cardinalidade (multiplicidade) 
 
 
Exclusividade Mútua 
Uma e somente uma das 
Ramificações são tomadas 
 
 
A 
A 
A 
A 
A 
B 
B 
B 
B 
B 
 17 
Atividades 
Caixa de cantos arredondados 
Representam atividades (funções, 
processos,procedimentos) 
 
 
 
 
 
 
A 
X 
Y 
Z 
A está associado a 
X, Y ou Z. 
A 
 
A 
A 
A 
A 
B 
B 
B 
B 
B 
Mínimo Máximo 
0 
 
 
 
1 
 
 
0 
 
 
1 
 
 
Mais do 
que 1 
 
 
1 
 
 
 
1 
 
 
Mais do 
que 0 
 
Mais do 
que 1Mais do 
que 1 
Fluxo ou seqüência 
 18 
Multiplicidade de Associação (cardinalidade): 
• É o número de instâncias de uma classe relacionada com uma 
instância de outra classe. 
• Para cada associação, há uma multiplicidade em cada direção. 
 
A notação usada pela UML, para os indicadores de multiplicidade, é: 
 
 Muitos -------- 
 Apenas Um ----------- 
 Zero ou Muitos------- 
 Um ou Muitos-------- 
 Zero ou Um--------- 
 
 
UML 
Linguagem de Modelagem Unificada 
 
1. Introdução 
 
As empresas modernas têm descoberto que o gerenciamento da informação como 
um recurso é uma questão estratégica para a sobrevivência em mercados cada vez mais 
competitivos e frente a fontes de recursos cada vez mais escassas. 
Diante dessa situação, os sistemas de informação tornaram-se peças-chave no 
gerenciamento da informação corporativa, e o sucesso no seu desenvolvimento, operação 
e manutenção tem significado, para as empresas, flexibilidade e capacidade competitiva 
no mercado, permitindo mais precisão e agilidade na tomada de decisão sobre o uso 
eficiente desses recursos. E os sistemas atuais tendem, cada vez mais, a serem mais 
complexos, maiores e dinâmicos do que os sistemas concebidos anteriormente. Portanto 
necessitam ser mais organizados, versáteis e flexíveis. 
Uma das grandes preocupações das organizações é a necessidade de se criar 
sistemas de informação rápidos, com qualidade e baixo custo. Por isto, tornou-se 
imprescindível a adoção de métodos que possam proporcionar mais estabilidade ao 
processo de desenvolvimento de sistemas de informação. 
Os métodos convencionais de desenvolvimento de sistemas (análise e projeto 
estruturado) apresentam algumas limitações que introduzem pontos de descontinuidade 
no processo de desenvolvimento de sistemas de informação. Estas limitações ocorrem 
principalmente por serem utilizados diagramas diferentes em cada fase do ciclo de vida 
de um sistema, acarretando perda de informação e inconsistências na transição de um 
diagrama para outro. 
* 
1 
 
0..* 
 
1..* 
 
0..1 
 19 
 Os métodos orientados a objetos utilizam um modelo único, o qual é utilizado em 
todas as fases do ciclo de vida de um sistema. Dessa forma, o processo de 
desenvolvimento de sistemas é simplificado, interativo e controlável. Cada iteração 
acrescenta características ao modelo, de forma a haver menores possibilidades de 
inconsistências e erros. 
O desenvolvimento de sistemas baseado em objetos concentra a maior parte do 
esforço na fase de análise de requisitos. Esse esforço adicional é compensado pela 
implementação mais rápida e mais simples do projeto. O sistema resultante é mais 
completo e de fácil manutenção devido ao encapsulamento e ao reuso. 
Grande parte de projetos de desenvolvimento de sistemas fracassam devido 
principalmente à má administração de riscos, construção de sistemas errados e por 
superestimar a tecnologia. 
Entre os riscos, podemos citar problemas de domínio de tecnologia, riscos 
financeiros, impossibilidade de fazer integração, inexistência de testes de requerimentos e 
código, requerimentos incompletos, ausência de interação com o usuário etc. 
Uma das maneiras de evitar o fracasso é definir um processo de desenvolvimento 
de sistemas. 
O processo de desenvolvimento de sistemas de informação é formado por um 
conjunto padronizado e documentado de atividades para todas as fases do ciclo de 
desenvolvimento. 
O processo de desenvolvimento tem que ser controlado e medido para facilitar a 
gerência dos riscos do projeto em cada fase, disciplinar a criatividade quando o 
desenvolvimento é feito em equipe e assegurar a qualidade do sistema. 
A escolha de uma metodologia constitui um dos passos mais importantes no 
processo de desenvolvimento de sistemas, e é através dela que as equipes e seus membros 
mantêm uma linguagem comum durante todo o ciclo de desenvolvimento. 
Os principais benefícios na adoção de metodologias são: 
• Permitir o compartilhamento da mesma filosofia de trabalho entre os 
desenvolvedores de sistemas de informação corporativos; 
• Evitar trabalho desnecessário; 
• Aumentar a produtividade; 
• Estabelecer pontos de verificação para acompanhamento e controle de 
execução do projeto de desenvolvimento; 
• Facilitar o envolvimento do usuário no projeto; 
• Prover uma notação e linguagem comum. 
 
Com a adoção de tecnologias orientadas a objetos o processo de desenvolvimento 
passa a ter um enfoque iterativo, com maior participação do usuário, foco em redução de 
riscos, alto nível de reuso e flexibilidade em relação aos requerimentos. 
O controle para o processo iterativo é suportado pelo "Rational Objectory 
Process". O Rational Objectory Process é estruturado em duas dimensões: 
 
Tempo - divisão do ciclo de vida em fases e iterações. 
 
 20 
Componentes - produção de um conjunto específico de artefatos com atividades 
bem definidas. 
 
 
A estruturação de um projeto através da dimensão 'tempo' envolve a adoção das 
seguintes fases: 
 
• Iniciação - especifica a visão do projeto. 
 
• Elaboração - analisa o domínio do problema, projeta a arquitetura apropriada, 
identifica elementos de riscos e desenvolve um plano abrangente de como será 
implementado o projeto. 
 
• Construção - desenvolve o produto através de iterações incrementais para a 
transição para os usuários. 
 
• Transição - promove a transição do produto para os usuários (liberação de 
versão e treinamento). 
Cada fase é concluída quando os objetivos específicos da respectiva fase são 
alcançados. As fases se tornaram mais flexíveis, sendo possível encontrar diversas partes 
do sistema em fases diferentes do ciclo de desenvolvimento. 
 Cada fase do ciclo de desenvolvimento de sistemas deve ser descrita de acordo 
com os seguintes tópicos: 
• Objetivos; 
• Produtos; 
• Atividades; 
• Pessoas envolvidas; 
• Medidas para avaliar a qualidade dos produtos (métricas). 
 
A estruturação de um projeto através da dimensão 'componente' envolve a 
realização das seguintes atividades realizadas ao longo do processo de desenvolvimento: 
 
• Análise de requisitos - descrição do que o sistema deve fazer. 
 
• Análise – detalhamento das atividades do sistema. 
 
• Projeto - como o sistema será implementado. 
 
• Implementação - desenvolvimento do código que resultará no sistema 
executável. 
 
• Teste - verificação do sistema inteiro. 
 21 
 
2. Histórico da UML 
 
Os estudos sobre a tecnologia de objetos iniciaram-se na década de 1980 com 
ênfase nas linguagens de programação. No final da mesma década começaram a surgir os 
métodos de análise e projeto. Os principais métodos foram de: 
• SHLAER & MELLOR (1989 e 1991); 
• COAD & YOURDON (1991); 
• COAD & NICOLA (1993); 
• COAD et al. (1995); 
• WIRFS-BROCK et al. (1990); 
• BOOCH (1994 e 1995); 
• RUMBAUGH et al. (1991 e 1996); 
• MARTIN & ODELL (1994 e 1995); 
• JACOBSON (1994 e 1995). 
 
Todos os métodos eram muito similares, apesar da existência de diferentes 
notações para representar o mesmo conceito, o que na verdade, causava muita confusão 
entre os técnicos e competição entre os metodologistas, o que provocou a “guerra dos 
métodos”. 
Em 1994 James Rumbaugh e Grady Booch iniciaram o trabalho de unificação dos 
métodos Booch e OMT. 
Em 1995 no OOPSLA , Booch e Rumbaught apresentaram a documentação da 
versão 0.8 do método unificado e anunciaram a integração de Ivar Jacobson na equipe, 
formando assim o que eles denominaram de “Three amigos”. 
Durante 1996 eles trabalharam no método que passou a chamar de Unified 
Modeling Language (UML) e a Object Management Group (OMG) iniciou um esforço 
para padronização na área de métodos. 
Os esforços de Rumbaugh, Booch e Jacobson resultaram as versões 0.9 e 0.91 da 
UML em junho e outubro de 1996 respectivamente. 
A UML é a sucessora da linguagem de modelagem encontrada nos métodos 
Booch, OOSE/Jacobson, OMT e outros como Modelos de Entidades e Relacionamentos. 
Cada um desses métodos era reconhecidomediante alguma forte característica. O 
OOSE é orientado a ‘use case’ e provê um excelente recurso para a análise de requisitos. 
A OMT foi expressiva para análise e sistemas centrados a dados. Booch’93 foi relevante 
na fase de projeto e construção de sistemas voltados para Engenharia. 
 22 
Durante 1996 a Rational Software Corporation contou com a participação de 
outras Instituições parceiras como: Hewlett-Packard, IBM, Microsoft, Oracle, Unisys, 
Platinum Technology, etc. Essa colaboração contribuiu para a produção da versão 1.0, 
uma versão bem definida, expressiva, poderosa e aplicável, a qual foi submetida a OMG 
para adoção. 
Em setembro de 1997 liberaram a versão1. 1 da UML e em dezembro a mesma 
foi aprovada como padrão pela OMG. 
Com a unificação dos métodos a UML alcançou dois objetivos: 
• Acabou com as diferenças existentes entre os métodos anteriores; 
• Unificaram as perspectivas entre os diferentes tipos de sistemas, fases de 
desenvolvimento e conceitos internos. 
 
 
2.1 – Método 
 
A UML não é um método é uma linguagem de modelagem designada para 
especificar, visualizar, construir e documentar um sistema. A linguagem de modelagem é 
a notação que o método utiliza para expressar projetos enquanto que o processo indica 
quais passos seguir para desenvolver um projeto. 
 A especificação da UML consiste de duas partes: 
• Semântica - especifica a sintaxe abstrata e a semântica dos conceitos de 
modelagem estática e dinâmica de objetos; 
• Notação – especifica a notação gráfica para a representação visual da 
semântica. 
A UML suporta o desenvolvimento iterativo e incremental. Desenvolvimento 
iterativo e incremental é o processo de desenvolvimento de sistemas em pequenos passos. 
Uma iteração é um laço de desenvolvimento que resulta na liberação de um subconjunto 
de produtos que evolui até o produto final percorrendo as seguintes atividades: 
 
• Análise de requisitos 
• Análise 
• Projeto 
• Implementação 
• Teste 
 
O detalhamento de cada etapa destas atividades define o método de 
desenvolvimento de sistemas. 
 
 
2.2 - Análise de requisitos 
 
Esta etapa se caracteriza pela definição do comportamento do sistema, ou seja, 
como o sistema age ou reage, descrevendo o relacionamento entre o ambiente e o 
sistema. Deve ser uma definição de necessidades do usuário e não uma proposta de 
solução. O usuário deve indicar os requisitos prioritários para o sistema. 
 23 
O grupo de análise deve identificar as necessidades do usuário. Decisões do 
projeto impostas não são características essenciais do domínio do problema. 
 A análise de requisitos compõe-se dos seguintes diagramas: 
 
• Diagrama de caso de uso; 
• Diagrama de seqüência; 
• Diagrama de colaboração; 
 
Para realizar a análise de requisitos, primeiramente deve-se: 
 
• Identificar objetivo e características do sistema; 
• Identificar os requisitos essenciais; 
• Descrever as necessidades do usuário; 
• Elaborar diagrama de caso de uso; 
• Elaborar diagrama de seqüência; 
• Elaborar diagrama de colaboraçã 
 
 
 3. Conceitos 
 
UML é uma linguagem visual para especificação (modelagem) de sistemas 
orientados a objeto. A UML privilegia a descrição de um sistema seguindo três 
perspectivas: 
1. Os diagramas de classes - (Dados estruturais); 
2. Os diagramas de casos de uso (Operações funcionais); 
3. Os diagramas de seqüência, atividades e transição de Estados (Eventos 
temporais). 
Os casos de uso de um projeto de software são descritos na linguagem UML 
através de Diagramas de Casos de Uso (Use Case). Diagrama de “Use Case”: É um 
diagrama usado para se identificar como o sistema se comporta em várias situações que 
podem ocorrer durante sua operação. Descrevem o sistema, seu ambiente e a relação 
entre os dois. Os componentes deste diagrama são os atores, os “Use Case” e os 
relacionamentos. Casos de uso e Relacionamentos. Ainda pode-se usar as primitivas 
Pacotes e Notas. 
 
Ator: Representa qualquer entidade que interage com o sistema durante sua execução 
essa interação se dá através de comunicações (troca de mensagens). Um ator pode ser 
uma pessoa (usuário, secretaria, aluno...), um dispositivo (impressora, máquina...), 
hardware (placa de modem, scaner...), softwares (sistema de bd, aplicativos...), etc. 
 
 
 
 
 24 
Algumas de suas características são descritas abaixo: 
 
• Ator não é parte do sistema. Representa os papéis que o usuário do sistema 
pode desempenhar. 
• Ator pode interagir ativamente com o sistema. 
• Ator pode ser um receptor passivo de informação. 
• Ator pode representar um ser humano, uma máquina ou outro sistema. 
 
Representação: 
 
 
 
 
 
 
 
 
 
OBS: Atores representam, na verdade, papeis desempenhados por pessoas, dispositivos 
ou outros quando interagem com o sistema. Um ator cujo identificador seja ALUNO não 
representa um aluno, mais sim um aluno qualquer, uma pessoa que esteja interagindo 
com o sistema na qualidade de aluno. 
 
Use Case: Como foi exemplificado acima, é uma seqüência de ações que o sistema 
executa e produz um resultado de valor para o ator. Modela o dialogo entre os atores e o 
sistema; é um fluxo de eventos completos. Algumas de suas características são descritas 
abaixo: 
 
• Um “Use Case” modela o diálogo entre atores e o sistema. 
• Um “Use Case” é iniciado por um ator para invocar uma certa funcionalidade 
do sistema. 
• Um “Use Case” é fluxo de eventos completo e consistente. 
• O conjunto de todos os “Use Case” representa todas as situações possíveis de 
utilização do sistema. 
 
Relacionamento: Os relacionamentos ligam as classes/objetos entre si criando 
relações lógicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos: 
• Associação: É uma conexão entre classes, e também significa que é uma conexão 
entre objetos daquelas classes. Em UML, uma associação é definida com um 
relacionamento que descreve uma série de ligações, onde a ligação é definida como a 
semântica entre as duplas de objetos ligados. 
• Generalização: É um relacionamento de um elemento mais geral e outro mais 
específico. O elemento mais específico pode conter apenas informações adicionais. 
Ator Use Case 
 25 
Uma instância (um objeto é uma instância de uma classe) do elemento mais 
específico pode ser usada onde o elemento mais geral seja permitido. 
 
Os relacionamentos em um diagrama de casos de uso podem envolver dois atores e 
dois casos de uso ou um ator e um caso de uso e assim sucessivamente. O relacionamento 
é representado através de uma 
 
 
Exemplo: Diagrama de “Use Cases” para um sistema automatizado de Matrícula num 
Curso 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Tipo de Relacionamento - Associações 
 
Uma associação representa que duas classes possuem uma ligação (link) entre elas, 
significando, por exemplo, que elas “conhecem uma a outra”, “estão conectadas com”, 
“para cada X existe um Y” e assim por diante. Classes e associações são muito poderosas 
quando modeladas em sistemas complexos. 
 
 
 
 
 
Professor 
Selecionar 
curso para 
ensinar 
Pedir lista 
dos 
matriculados 
Gerencia
r 
Manter 
informação de 
Manter 
informação de 
professor 
Gerar catalogo 
Manter 
informações dos 
cursos 
Sistema 
de 
cobrança 
Matrícula 
nos 
Cursos 
Aluno 
 26 
1.1 Associações Normais 
 
O tipo mais comum de associação é apenas uma conexão entre classes. É 
representada por uma linha sólida entre duas classes. A associação possui um nome 
(junto à linha que representa a associação), normalmente um verbo, mas substantivos 
também são permitidos. 
Pode-se também colocar uma seta no final da associação indicando que esta só pode 
ser usada para o lado onde a seta aponta. Mas associações também podem possuir dois 
nomes, significando um nome para cada sentido da associação. 
Para expressar a multiplicidade entre os relacionamentos, um intervalo indica 
quantos objetos estão relacionados no link. O intervalo pode ser de zero para um (0..1), 
zero para vários (0..*ou apenas *), um para vários (1..*), dois (2), cinco para 11 (5..11) e 
assim por diante. É também possível expressar uma série de números como (1, 4, 6..12). 
Se não for descrita nenhuma multiplicidade, então é considerado o padrão de um para um 
(1..1 ou apenas 1). 
Cliente Conta CorrentePossui �
 É possuído 
 
Duas classes se relacionando por associação normal 
 
No exemplo acima vemos um relacionamento entre as classes Cliente e Conta 
Corrente que se relacionam por associação. 
 
1.2 - Associação Recursiva 
É possível conectar uma classe a ela mesma através de uma associação e que ainda 
representa semanticamente a conexão entre dois objetos, mas os objetos conectados são 
da mesma classe. Uma associação deste tipo é chamada de associação recursiva. 
Pessoa
Marido
Esposa
 é casado com
 
 Exemplo de uma associação recursiva 
 
1.3 - Associação Ternária 
 27 
 
Mais de duas classes podem ser associadas entre si, a associação ternária associa três 
classes. Ela é mostrada como uma grade losango (diamante) e ainda suporta uma 
associação de classe ligada a ela, traçaria-se, então, uma linha tracejada a partir do 
losango para a classe onde seria feita a associação ternária. 
 
Regras Contratuais
Contrato Cliente0..* 1..*
1..*
 
Exemplo de uma associação ternária 
 
No exemplo acima a associação ternária especifica que um cliente poderá possuir 1 
ou mais contratos e cada contrato será composto de 1 ou várias regras contratuais. 
 
 
1.4 - Agregação 
 
A agregação é um caso particular da associação. A agregação indica que uma das classes 
do relacionamento é uma parte, ou está contida em outra classe. As palavras chaves 
usadas para identificar uma agregação são: “consiste em”, “contém”, “é parte de”. 
• É uma forma especializada de associação na qual um todo é relacionado com 
suas partes. Também conhecida como relação de conteúdo. 
• É representada como uma linha de associação com um diamante junto à 
Classe agregadora. 
• A multiplicidade é representada da mesma maneira que nas associações. 
 
 
 
NaviosMarinha
*
contém
*
 
Exemplo de uma agregação entre duas classes 
 28 
 
Tipo de Relacionamento - Generalizações 
 
A generalização é um relacionamento entre um elemento geral e um outro mais 
específico. O elemento mais específico possui todas as características do elemento geral e 
contém ainda mais particularidades. Um objeto mais específico pode ser usado como uma 
instância do elemento mais geral. A generalização, também chamada de herança, permite 
a criação de elementos especializados em outros. 
Existem alguns tipos de generalizações que variam em sua utilização a partir da 
situação. São elas: generalização normal e restrita. As generalizações restritas se dividem 
em generalização de sobreposição, disjuntiva, completa e incompleta. 
 
1.1 - Generalização Normal 
 
Na generalização normal a classe mais específica, chamada de subclasse, herda tudo 
da classe mais geral, chamada de superclasse. Os atributos, operações e todas as 
associações são herdados. 
 
Conta Corrente Poupança
 
Exemplo de uma generalização normal 
 
Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver 
numa hierarquia de classes que é um gráfico onde as classes estão ligadas através de 
generalizações. 
A generalização normal é representada por uma linha entre as duas classes que 
fazem o relacionamento, sendo que se coloca uma seta no lado da linha onde se encontra 
a superclasse indicando a generalização. 
 
1.2 - Generalização Restrita 
 
Uma restrição aplicada a uma generalização especifica informações mais precisas 
sobre como a generalização deve ser usada e estendida no futuro. As restrições a seguir 
definem as generalizações restritas com mais de uma subclasse: 
 
• Generalizações de Sobreposição e Disjuntiva: Generalização de sobreposição 
significa que quando subclasses herdam de uma superclasse por sobreposição, novas 
 29 
subclasses destas podem herdar de mais de uma subclasse. A generalização disjuntiva 
é exatamente o contrário da sobreposição e a generalização é utilizada como padrão. 
 
Veículo
BarcoCarro
Anfíbio
{sobreposição}
 
Exemplo de uma generalização de sobreposição 
 
• Generalizações Completa e Incompleta: Uma restrição simbolizando que 
uma generalização é completa significa que todas as subclasses já foram 
especificadas, e não existe mais possibilidade de outra generalização a partir 
daquele ponto. A generalização incompleta é exatamente o contrário da 
completa e é assumida como padrão da linguagem. 
 
Pessoa
MulherHomem
{completa}
 
 Exemplo de uma generalização completa 
 
 
 
 
 
 
 30 
 
 
 
 
Diagrama de Seqüência 
 
 Em um sistema computacional orientado a objeto os serviços (casos de uso) são 
fornecidos através da colaboração de grupos. Os objetos interagem através de comunicações de 
forma que juntos, cada um com suas responsabilidades, realizem os casos de uso. 
 O Diagrama de seqüência é uma ferramenta importante no projeto de sistemas orientados 
a objetos. Embora a elaboração dos diagramas possa consumir um tempo considerável para 
sistemas maiores ou mais complexos, eles oferecem a seguir as bases para a definição de uma 
boa parte do projeto como: os relacionamentos necessários entre as classes, métodos e atributos 
das classes e comportamento dinâmico dos objetos. 
Um diagrama de seqüência é um diagrama de objetos, ou seja, ele contém como primitiva 
principal um conjunto de objetos de diferentes classes. O objetivo dos diagramas de seqüência 
é descrever as comunicações necessárias entre objetos para a realização dos processos em um 
sistema computacional. Os diagramas de seqüência têm este nome porque descrevem ao longo 
de uma linha de tempo a seqüência de comunicações entre objetos. Como podem existir muitos 
processos em um sistema computacional, sugere-se proceder à construção dos diagramas de 
seqüência por caso de uso. Assim, tomar-se-ia separadamente cada caso de uso para a 
construção de seus diagramas de seqüência. De uma forma geral, para cada caso de uso 
constrói-se um diagrama de seqüência principal descrevendo as seqüências normais de 
comunicação entre objetos e diagramas complementares descrevendo seqüências alternativas e 
tratamento de situações de erro. 
Utiliza-se também o termo cenário associado com os diagramas de seqüência. Um 
cenário é uma forma de ocorrência de um caso de uso. Como o processo de um caso de uso 
pode ser realizado de diferentes formas, para descrever a realização de um caso de uso pode ser 
necessário estudar vários cenários. Cada cenário pode ser descrito por um diagrama de 
seqüência. No exemplo do caso de uso Cadastrar Aluno do sistema de controle acadêmico, 
podem-se considerar os cenários de inclusão, alteração e exclusão de aluno. 
 
Notação UML para Diagramas de Seqüência 
 
A notação UML para descrição de diagramas de seqüência envolve a indicação do 
conjunto de objetos envolvidos em um cenário e a especificação das mensagens trocadas entre 
estes objetos ao longo de uma linha de tempo. Os objetos são colocados em linha na parte 
superior do diagrama. Linhas verticais tracejadas são traçadas da base dos objetos até a parte 
inferior do diagrama representando a linha de tempo. O ponto superior destas linhas indica um 
instante inicial e, à medida que se avança para baixo evolui-se o tempo. Retângulos colocados 
sobre as linhas de tempo dos objetos indicam os períodos de ativação do objeto. Durante um 
período de ativação, o objeto respectivo esta em execução realizando algum processamento. 
Nos períodos em que o objeto não esta ativo, ele esta alocada (ele existe), mas não esta 
 31 
executando nenhuma instrução. A figura abaixo ilustra a estrutura básica de um diagrama de 
seqüência para o cenário Inclusão de Aluno do caso de uso Cadastrar Aluno. 
 
 : SGBD
Interface 
Secretaria
Controle 
Cadastrar Aluno
Aluno Interface SGBD
 : Secretaria
1: 
2: 
3: 
 
Figura – Estrutura básicade um diagrama de seqüência 
 
 
Outra primitiva importante dos diagramas de seqüência é a troca de mensagem. Esta 
primitiva é utilizada para indicar os momentos de interação ou comunicação entre os objetos. 
Utiliza-se como notação para trocas de mensagens segmentos de retas direcionadas da linha de 
tempo de um objeto origem para a linha de tempo de um objeto destino. Uma seta é colocada 
na extremidade do objeto destino. As linhas representando troca de mensagens são desenhadas 
na horizontal, pois se presume que a troca de uma mensagem consome um tempo desprezível. 
O objeto destino de uma mensagem deve receber a mensagem e processa-la. Desta forma, 
no recebimento de uma mensagem o objeto destino é ativado para tratamento da mensagem. A 
figura abaixo ilustra a troca de mensagens entre objetos e entre atores e objetos. 
 
 32 
 : Secretaria
Interface 
Secretaria
Controle 
Cadastrar Aluno
Aluno
1: 
3: 
Janela
Dados
2: Mostrar Janela
4: Registrar (Dados)
5: Acessar (codigo)
Figura - Exemplo de troca de mensagem em um diagrama de sequencia 
 
 
As mensagens trocadas entre um objeto ou entre um objeto e um ator podem ter três 
significados: 
 
· Chamada de Função ou Procedimento 
 
Uma das interações mais freqüentes entre objetos é a chamada de função. Uma chamada 
de função significa que um objeto esta solicitando a execução de uma função (um método) de 
um outro objeto. Este conceito segue estritamente o processo de chamada de função ou de 
procedimento utilizado nas linguagens de programação. Obviamente, para que um objeto possa 
chamar um método de outro objeto é necessário que o método seja declarado como publico na 
classe respectiva. Como será visto a seguir, a sintaxe, no caso de mensagens que representem 
chamadas de função, é semelhante àquela das linguagens de programação. 
 
· Envio de Mensagem 
 
Objetos também podem comunicar-se com outros objetos através do envio explıcito de 
uma mensagem. O envio de uma mensagem, ao contrario da chamada de função, não é uma 
interação direta entre dois objetos. Na verdade, quando um objeto envia uma mensagem a 
outro objeto, a mensagem é roteada ou encaminhada por algum mecanismo de entrega de 
mensagens. Normalmente, este serviço é prestado pelo sistema operacional através de 
mecanismos como Message Queres (filas de mensagens) ou serviços de notificação. 
 
· Ocorrência de Evento 
 
Existem também outras formas de interação entre objetos através de eventos. Esta é 
também a forma padrão de interação entre objetos e atores. Basicamente, um evento é algum 
acontecimento externo ao software, mas que é a ele notificado, pois lhe diz respeito. A 
notificação, ou seja, a indicação de que um determinado evento ocorreu é, na maioria dos 
 33 
casos, feita pelo sistema operacional. Eventos podem também ser gerados pelo software para o 
sistema operacional. Exemplos são as saídas para dispositivos (monitor, porta serial, disco) 
feitos através de serviços do sistema operacional. 
 
Alguns exemplos de eventos são: 
 
Evento Origem Destino 
 
Clique do mouse mouse Algum objeto 
 
Movimentação do mouse mouse Algum objeto 
 
Dados no buffer do teclado teclado Algum objeto 
 
Dados no buffer da serial porta serial Algum objeto 
 
Projeção de dados no 
monitor. 
Bip do alto-falante. 
Algum objeto 
 
Algum objeto 
 
monitor 
 
alto-falante 
Colocação de dados no 
buffer da serial 
Algum objeto Porta serial 
 
Interrupção Dispositivo de 
hardware 
 
Algum objeto 
Eventos do sistema 
operacional (timer) 
Sistema operacional Algum objeto 
 
 
Tipos de Mensagens 
 
Nos exemplos das figuras utilizou-se como notação gráfica para as trocas de mensagens 
segmentos de reta com uma seta aberta em uma das extremidades. Esta é a notação genérica 
para mensagens que pode ser utilizada nas primeiras versões dos diagramas de seqüência. Em 
diagramas mais detalhados, entretanto, será utilizada outra notação deforma a indicar também 
o tipo das mensagens. Existem dois tipos de mensagens chamadas mensagens síncronas e 
assíncronas. 
 
· Mensagens Síncronas 
 
Mensagens síncronas são mensagens que implicam um sincronismo rígido entre os 
estados do objeto que envia a mensagem e os do objeto de destino da mensagem. Um 
sincronismo entre objetos pode ser entendido, de uma forma geral, como uma dependência na 
evolução de estado de um objeto sobre o estado de um segundo objeto. De uma forma mais 
direta, pode-se dizer que uma mensagem síncrona implica que o objeto que enviou a 
mensagem aguarde a conclusão do processamento da mensagem (entendida como um sinal de 
sincronismo) feito pelo objeto destino, para então prosseguir seu fluxo de execução. O exemplo 
 34 
mais comum de mensagem síncrona é a chamada de função. Em uma chamada de função o 
objeto que faz a chamada ü empilhado e fica neste estado até a conclusão do processamento da 
função chamada. Trata-se, portanto, de um sincronismo rígido entre o objeto chamador e o 
objeto chamado. Alguns sistemas operacionais oferecem também mecanismos de troca de 
mensagens síncronas de forma que o objeto que envia a mensagem fique em estado de espera 
até a conclusão do tratamento da mensagem. 
A notação UML para uma mensagem síncrona é a de um segmento de reta com uma seta 
cheia em uma das extremidades 
 
· Mensagens Assíncronas 
 
Mensagens assíncronas são mensagens enviadas de um objeto a outro sem que haja uma 
dependência de estado entre os dois objetos. O objeto de origem envia a mensagem e 
prossegue seu processamento independentemente do tratamento da mensagem feita no objeto 
destino. Os mecanismos de envio de mensagens suportados pelos sistemas operacionais são o 
exemplo mais comum deste tipo de mensagem. Além disso, de uma forma geral, todas as 
comunicações entre atores e objetos representam trocas de mensagem assíncronas. Considere, 
por exemplo, uma operação para apresentação de uma mensagem no monitor. Um objeto 
executa uma instrução print (ou print ou write) e o sistema despacha a mensagem para o ator (o 
monitor). O objeto prossegue seu processamento independentemente do desfecho na operação. 
Observe que os softwares não bloqueiam quando o monitor não apresenta alguma informação. 
A notação UML para uma mensagem assíncrona é a de um segmento de reta com uma meia 
seta em uma das extremidades. 
 
 
 Além desta diferenciação entre mensagens síncronas e assíncronas, pode-se também 
indicar quando uma mensagem consome tempo. A notação UML para mensagens deste tipo é 
ilustrada na figura abaixo. 
 
 
· Autodelegação 
 
Um objeto pode enviar mensagens para outros objetos e pode também enviar mensagens 
para ele próprio. Uma mensagem enviada de um objeto para ele próprio chama-se uma 
Autodelegação. Mensagens de Autodelegação podem ser síncronas ou assíncronas. O caso 
mais comum de mensagens assíncronas é o envio de uma mensagem de um objeto para ele 
mesmo através de mecanismos de envio de mensagens do sistema operacional. O caso mais 
comum de mensagens de Autodelegação síncronas é a chamada de função de um objeto pelo 
próprio objeto. 
 
 35 
Controle 
cadastrar aluno
1: Calcular
2: Fim processo
 
Figura – Notação UML para autodelegação 
 
 
 
 
Diagrama de Colaboração 
 
Mostra a interação organizada ao lado de cada classe de objetos e a ligação entre elas. 
Como o diagrama de seqüência, o diagrama de colaboração mostra as mensagens trocadas por 
um conjunto de objetos durante um cenário. É uma representação gráfica alternativa para 
mostrar um cenário. Descrevem grupos de objetos que colaboram através de comunicação. 
Um diagrama de colaboração contém: 
 
• Objetos, que são representados por retângulos. 
• Ligações entre objetos, representadas por uma linha conectando os objetos. 
• Mensagens trocadas entre objetos em uma seqüência ordenada 
• Fluxo de dados entre objetos, se houver. 
 
Através do diagrama de colaboração é mais fácil visualizar as mensagens trocadas entre 
os objetos, subsidiando assim a elaboração do diagrama de classesde objetos. Os objetos e as 
mensagens são as mesmas do diagrama de seqüência. Utilizando o diagrama de colaboração é 
possível identificar se existe algum objeto que não troca mensagens com outro. Caso isto 
aconteça deve-se analisar o modelo de origem e verificar se este objeto é mesmo necessário. 
Os diagramas de seqüência e de colaboração serão mais utilizados no desenvolvimento do 
projeto quando são projetadas as implementações dos relacionamentos. 
O objetivo do diagrama de colaboração é agrupar as mensagens entre pares de objetos de 
forma a fazer-se um levantamento das necessidades de comunicação. 
 
 
 
 
 36 
Diagrama de Estado 
 
 O comportamento de uma classe de objetos é representado através de um 
diagrama de transição de estado, que descreve o ciclo de vida de uma dada classe, os 
eventos que causam a transição de estado para o outro e as ações resultantes da mudança 
de estado. 
 O estado de um objeto é uma das possíveis condições na qual o objeto pode 
existir. O estado compreende todas as propriedades do objeto associadas aos valores 
correntes de cada uma dessas propriedades. 
 Segundo a UML a especificação da dinâmica do sistema deve ser feita através de 
diagramas de estados. Constrói-se um diagrama de estado descrevendo o comportamento 
de cada classe e eventuais diagramas comportamentais para descrever a dinâmica de todo 
o sistema ou de certos módulos. 
• Diagrama de estado é uma descrição global do comportamento dos objetos desta 
classe em todo o sistema; 
• Diagrama de estado; a especificação da dinâmica do sistema deve ser feita através 
de diagramas de classe; 
• Descreve-se o conjunto de estados de um objeto e também o conjunto de 
transações de estados existentes. 
 
A UML utiliza como notação para diagramas de estados a notação proposta por 
Harel. Nesta notação, um diagrama de estados e um grafo dirigido cujos nodos 
representam estados e cujos arcos representam transições entre estados. Estados são 
representados graficamente por elipses ou retângulos com bordas arredondadas e 
transições são representadas por segmento de retas dirigidas. 
 
Notação do Diagrama de Estado 
 
 Estado Inicial 
 
 Estado Final 
 
 
 
 
 
 
Estado Intermediário 
Transição de Estado 
 
 37 
 
Estado – pode ser entendido como um momento na vida de um objeto, momento em que 
foi criado, momento em que fez uma inicialização, momento de solicitação, etc. Os 
estados são identificados com nomes no gerúndio e particípio. O mesmo estado pode ser 
repetido. Existem duas notações gráficas especiais para dois estados particulares 
existentes em diagramas de estados. Utiliza-se a notação de um circulo preenchido para 
indicar o estado de partida do objeto. Pode-se entender que ele representa o momento de 
criação ou alocação do objeto. Utiliza-se a notação de dois círculos para representar o 
estado final de um objeto. O estado final representa o momento de destruição ou 
desalocação do objeto. 
 
 
 
 
 
 Estado Inicial Estados Intermediários Estado Final 
 
Exemplos de Estados de um Objeto 
 
Transição de Estados – Os estados tendem a avançar de um certo estado para algum 
outro a medida que executem seus processamentos. Este avanço de uma situação (estado) 
para outro se denomina uma transição de estado. A transição de estado possui um rotulo, 
com a seguinte sintaxe: 
 
Evento (argumento) [condição/Ação] 
 
 
 
Evento – indica uma mensagem ou notificação recebida pelo objeto e que torna a 
transição habilitada. 
Argumento – são valores recebidos junto com o evento. 
Condição – é uma expressão lógica que é avaliada quando o evento associado a uma 
transição ocorre. Uma transição só ocorre se o evento acontecer e a condição associada 
for verdadeira. 
Ação – indica uma ação que é executada durante a transição de um estado a outro. 
 
 
 
 Estado Inicial Estado final 
 
 
Exemplo de Diagrama de Estados 
 
 
 
Mostrand
o janela 
Aguardand
o Dados 
Dados 
recebidos 
Dados 
 38 
Clausula de Envio 
 
• É uma ação de envio de uma mensagem do objeto que se esta modelando para 
algum outro objeto. O envio pode ser síncrono ou assíncrono; 
• Em diagramas de estados, indica-se que o objeto está enviando uma mensagem a 
outro objeto colocando-se uma clausula de envio como uma ação em uma 
transição. 
 ^ nome_objeto. Nome_mensagem 
 
 
 
 
Diagrama de Atividades 
 
 Um diagrama de atividades é um diagrama de estado no qual se considera que 
todos ou a grande maioria dos estados representam a execução de ações ou atividades. A 
notação UML para diagramas de atividades utiliza as mesmas primitivas dos diagramas 
de estados e inclui algumas notações adicionais. 
 As novas primitivas incluídas nos diagrama de atividades são: 
• Estado de Bifurcação e de Convergência 
Bifurcação - é um estado do qual partem duas ou mais transições. A notação utilizada 
para o estado de bifurcação é na forma de um losango. 
Convergência – é um estado que possui mais de uma transição de entrada representando, 
desta forma, um ponto de junção de fluxos alternativos dentro de um diagrama de 
estados. A notação utilizada para o estado de convergência é na forma de um losango. 
 39 
 
 Exemplo de Estados de Bifurcação e de Convergência 
• Sincronismo de Concorrências 
 
Os diagramas de atividades empregam uma notação permitindo a especificação de 
sincronismo de concorrências. A mesma notação, na forma de uma barra preenchida, é 
utilizada tanto para abertura de sincronismo quanto para sincronismo de concorrências. 
Na abertura, entende-se que os fluxos seguintes avançarão concorrentemente. O 
sincronismo de encerramento de concorrências representa um ponto de aguardo até que 
todos os fluxos concorrentes alcancem o ponto de sincronismo. 
Esperando Opção 
Iniciando 
Processo 1 
Iniciando 
Processo 2 
Processo 1 
Encerrado 
Processo 2 
Encerrado 
Encerrando 
Ativação 
Estado de Convergência 
^interf.Processo1 ^interf. Processo2 
Estado de Bifurcação 
 40 
 
 Exemplo de Abertura e sincronismo de encerramento de concorrências 
 
Esperando Opção 
Iniciando 
Processo 1 
Iniciando 
Processo 2 
Processo 1 
Encerrado 
Processo 2 
Encerrado 
Encerrando 
Ativação