Análise Orientada A Objetos II

Análise Orientada a
Objetos II
Profa. Simone Cristina Aléssio
2015
Copyright © UNIASSELVI 2015
Elaboração:
Profa. Simone Cristina Aléssio
Revisão, Diagramação e Produção:

Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

UNIASSELVI – Indaial.
005.1
A372a Aléssio, Simone Cristina
Análise orientada a objetos II/ Simone Cristina Aléssio.
Indaial : UNIASSELVI, 2015.
156 p. : il.
ISBN 978-85-7830-934-3
1. Programação Orientada a Objetos.

I. Centro Universitário Leonardo Da Vinci.
Apresentação
Prezado(a) acadêmico(a)! Seja bem-vindo(a) ao mundo da
Programação Orientada a Objetos.
Neste universo você vai se deparar com termos como atributos,

métodos, abstração, encapsulamento, classes, hierarquia das classes, processo
unificado, entre outros, que compõem o material de estudo desta disciplina e,
por consequência, o dia a dia de um analista, desenvolvedor, programador,
ou seja, o profissional da programação.
Este caderno pressupõe que você já possua alguma experiência

anterior em programação, principalmente JAVA, afinal, muitos dos objetos,
classes e diagramas apresentados neste material estão voltados a esta
linguagem de programação. É essencial você fazer uso dos conhecimentos
adquiridos em disciplinas anteriores para então conseguir acompanhar o
desenvolvimento de um sistema e, assim, auxiliar você na construção do
entendimento em programação orientada a objetos.
Aproveito a oportunidade para destacar a importância de desenvolver

as autoatividades, afinal, cada exercício deste caderno foi desenvolvido para
a fixação de conceitos por meio da prática. Em caso de dúvida na realização
das atividades, sugiro que você entre em contato com seu tutor externo ou
com a tutoria da UNIASSELVI, não prosseguindo as atividades sem ter
sanado todas as dúvidas que irão surgindo.
Vale destacar a necessidade de dedicação e de muita determinação,

afinal, a Programação Orientada a Objetos exige de você bem mais do que
apenas este caderno para sua total compreensão. Aqui você recebe somente
um início, ou seja, os conceitos de determinados pontos importantes na
programação, porém, é somente na prática que você consegue compreender
o mundo da programação como um todo.
Lembre-se de que o mundo da informática é encantador, assim, seu

entusiasmo por este universo depende somente de você, destacando neste
momento a compreensão da lógica envolvida no processo de construção de
programas. Por este motivo, destaco uma frase que considero importante
no caso da programação, afinal: “Para se ter sucesso, é amar de verdade o
que se faz. Caso contrário, levando em conta apenas o lado racional, você
simplesmente desiste. É o que acontece com a maioria das pessoas” (Steven
Jobs – criador da Apple).
Bom estudo! Sucesso na sua trajetória acadêmica e profissional!
Simone Cristina Aléssio

III
NOTA
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto

para você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há
novidades em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é

o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um
formato mais prático, que cabe na bolsa e facilita a leitura.
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova
diagramação no texto, aproveitando ao máximo o espaço da página, o que também
contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente,

apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade
de estudá-lo com versatilidade nas telas do celular, tablet ou computador.

Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto
em questão.
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de

Desempenho de Estudantes – ENADE.

Bons estudos!
IV
V
VI
Sumário
UNIDADE 1 – REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE
CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL:
CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE
MÁQUINA DE ESTADOS........................................................................................... 1
TÓPICO 1 – REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE

CONCEITOS DA UML..................................................................................................... 3
1 INTRODUÇÃO...................................................................................................................................... 3
2 ORIENTAÇÃO A OBJETOS................................................................................................................ 5
2.1 ABSTRAÇÃO..................................................................................................................................... 5
2.2 CLASSE.............................................................................................................................................. 6
2.2.1. Método..................................................................................................................................... 7
2.2.2 Responsabilidades................................................................................................................... 7
2.2.3 Tipos de relacionamento entre classes.................................................................................. 8
2.2.4 Mensagem................................................................................................................................. 10
2.2.5 Objeto........................................................................................................................................ 10
3 PROJETO ORIENTADO A OBJETOS............................................................................................... 10
4 AS VÁRIAS OPÇÕES DA UML......................................................................................................... 11
4.1 CONCEITOS DA ESTRUTURA DA UML.................................................................................... 12
4.1.1 Itens............................................................................................................................................ 12
4.1.2 Itens estruturais........................................................................................................................ 12
4.1.3 Itens comportamentais............................................................................................................ 15
4.1.4 Itens de agrupamento............................................................................................................. 15
4.1.5 Item anotacional....................................................................................................................... 16
4.2 DIAGRAMAS.................................................................................................................................... 16
RESUMO DO TÓPICO 1........................................................................................................................ 19
AUTOATIVIDADE.................................................................................................................................. 20
TÓPICO 2 – MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, DIAGRAMA

DE CASOS DE USO.......................................................................................................... 21
1 INTRODUÇÃO...................................................................................................................................... 21
2 UML.......................................................................................................................................................... 22
3 DIAGRAMAS DA UML....................................................................................................................... 23
3.1 DIAGRAMAS ESTRUTURAIS................................................................................................... 25
3.2 DIAGRAMAS COMPORTAMENTAIS..................................................................................... 25
4 DIAGRAMAS COMPORTAMENTAIS ........................................................................................... 26
4.1 DIAGRAMA DE CASOS DE USO................................................................................................. 27
4.2 ELEMENTOS DO DIAGRAMA DE CASOS DE USO................................................................. 27
4.3 ELEMENTO ATORES...................................................................................................................... 28
4.4 ELEMENTO CASOS DE USO......................................................................................................... 28
4.4.1 Descrição................................................................................................................................... 29
5 FLUXO DE EVENTOS.......................................................................................................................... 29
5.1 FLUXO BÁSICO................................................................................................................................ 30
VII
5.2 SUBFLUXO........................................................................................................................................ 30
5.2.1 Pontos de extensão.................................................................................................................. 31
5.3 FLUXO ALTERNATIVO.................................................................................................................. 31
6 ELEMENTO RELAÇÕES...................................................................................................................... 32
6.1 ASSOCIAÇÃO................................................................................................................................... 32
6.2 ATOR X ATOR................................................................................................................................... 32
6.3 ATOR X CASO................................................................................................................................... 32
6.4 ELEMENTO DEPENDÊNCIA - INCLUSÃO E EXTENSÃO..................................................... 33
7 EXTENSÃO............................................................................................................................................. 34
8 ELEMENTO GENERALIZAÇÃO/ESPECIALIZAÇÃO................................................................. 34
9 DICAS IMPORTANTES....................................................................................................................... 36
RESUMO DO TÓPICO 2........................................................................................................................ 39
AUTOATIVIDADE.................................................................................................................................. 40
TÓPICO 3 – DIAGRAMA DE ATIVIDADES E DIAGRAMA DE

MÁQUINA DE ESTADOS............................................................................................... 43
1 INTRODUÇÃO...................................................................................................................................... 43
2 AÇÃO....................................................................................................................................................... 45
3 ATIVIDADES......................................................................................................................................... 45
4 EVENTOS................................................................................................................................................ 45
5 NÓS DE CONTROLE........................................................................................................................... 45
6 PONTOS DE EXTENSÃO.................................................................................................................... 45
7 OUTROS RECURSOS EM DIAGRAMAS DE ATIVIDADES..................................................... 47
8 RELAÇÃO COM OUTROS DIAGRAMAS...................................................................................... 47
9 EXEMPLO DE CRIAÇÃO DE DIAGRAMA DE ATIVIDADES.................................................. 48
LEITURA COMPLEMENTAR................................................................................................................ 53
RESUMO DO TÓPICO 3........................................................................................................................ 61
AUTOATIVIDADE.................................................................................................................................. 62
UNIDADE 2 – DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)....................................... 65
TÓPICO 1 – DIAGRAMAS DE INTERAÇÃO................................................................................... 67

1 INTRODUÇÃO...................................................................................................................................... 67
2 DIAGRAMA DE SEQUÊNCIA........................................................................................................... 67
2.1 TIPOS DE MENSAGEM.................................................................................................................. 68
2.2 DIAGRAMA DE COMUNICAÇÃO.............................................................................................. 70
2.2.1 Principais componentes: objetos, mensagens e vínculo..................................................... 71
2.2.2 Notação: semelhante ao Diagrama de Sequência............................................................... 72
2.2.3 Atores......................................................................................................................................... 73
2.2.4 Condições.................................................................................................................................. 73
2.2.5 Autochamadas . ....................................................................................................................... 74
2.2.6 Exemplo de Diagrama de Comunicação.............................................................................. 74
2.3 DIAGRAMA DE TEMPO................................................................................................................ 75
2.4 DIAGRAMA DE VISÃO GERAL................................................................................................... 76
RESUMO DO TÓPICO 1........................................................................................................................ 77
AUTOATIVIDADE.................................................................................................................................. 79
TÓPICO 2 – DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES

1 INTRODUÇÃO...................................................................................................................................... 81
2 DIAGRAMA DE CLASSES................................................................................................................. 81
2.1 CENÁRIO........................................................................................................................................... 82
VIII
2.2 IDENTIFICAR OS OBJETOS TANGÍVEIS.................................................................................... 84
2.3 AGRUPAR OS OBJETOS POR SEMELHANÇA.......................................................................... 85
2.4 DELIMITAR CLASSES REDUNDANTES OU QUE NÃO SÃO NECESSÁRIAS................... 85
2.5 MONTANDO O DIAGRAMA DE CLASSE................................................................................. 85
2.6 REALIZANDO AS PRIMEIRAS LIGAÇÕES................................................................................ 86
3 DIAGRAMA DE CLASSE COMPLETO........................................................................................... 88
3.1 DIAGRAMA DE PACOTES............................................................................................................ 89
3.1.1 Definindo as classes de um Pacote........................................................................................ 90
3.1.2 Principais componentes: pacotes........................................................................................... 91
RESUMO DO TÓPICO 2........................................................................................................................ 93
AUTOATIVIDADE.................................................................................................................................. 95
TÓPICO 3 – DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE COMPONENTES............... 97

1 INTRODUÇÃO...................................................................................................................................... 97
2 PRINCIPAIS COMPONENTES: OBJETOS, RELACIONAMENTOS ..................................... 97
3 DIAGRAMA DE COMPONENTES................................................................................................... 99
3.1 PRINCIPAIS COMPONENTES: COMPONENTES, INTERFACES, CLASSES E
RELACIONAMENTOS ................................................................................................................... 99
3.1.1 Componente........................................................................................................................... 100
3.1.2 Objetivos................................................................................................................................. 100
3.1.3 Diagrama de Componentes.................................................................................................. 101
LEITURA COMPLEMENTAR.............................................................................................................. 103
RESUMO DO TÓPICO 3...................................................................................................................... 107
AUTOATIVIDADE................................................................................................................................ 108
UNIDADE 3 – DIAGRAMAS ESTRUTURAIS................................................................................ 109
TÓPICO 1 – DIAGRAMA DE IMPLANTAÇÃO E ESTRUTURA COMPOSTA....................... 111

1 INTRODUÇÃO.................................................................................................................................... 111
2 PRINCIPAIS COMPONENTES........................................................................................................ 112
3 DIAGRAMA DE ESTRUTURA COMPOSTA............................................................................... 113
RESUMO DO TÓPICO 1...................................................................................................................... 117
AUTOATIVIDADE................................................................................................................................ 118
TÓPICO 2 – INTEGRAÇÃO DOS DIAGRAMAS – UMA VISÃO GERAL DO

DESENVOLVIMENTO USANDO UML........................................................................................... 119
1 INTRODUÇÃO.................................................................................................................................... 119
2 EXEMPLO DE DESENVOLVIMENTO DE PROJETOS USANDO UML................................ 119
RESUMO DO TÓPICO 2...................................................................................................................... 123
AUTOATIVIDADE................................................................................................................................ 124
TÓPICO 3 – ESTUDO DE CASO........................................................................................................ 125

1 INTRODUÇÃO.................................................................................................................................... 125
2 NECESSIDADE DE COMPREENDER OS PROCESSOS DA ORGANIZAÇÃO.................. 126
2.1 O MAPEAMENTO DE PROCESSOS . ........................................................................................ 127
2.1.1 Fluxograma . .......................................................................................................................... 128
2.1.2 SADT (Structured Analysis and Design Technic).................................................................. 129
2.1.3 IDEF3 ...................................................................................................................................... 129
2.1.4 UML (Unified Modeling Language)........................................................................................ 130
2.1.5 Diagrama de Atividades....................................................................................................... 130
2.1.6 Aplicação do Diagrama de Atividades da UML............................................................... 131
IX
2.1.7 Avaliação da Aplicação do Diagrama de Atividades....................................................... 136
2.1.8 Conclusões ............................................................................................................................. 137
LEITURA COMPLEMENTAR.............................................................................................................. 138
RESUMO DO TÓPICO 3...................................................................................................................... 150
AUTOATIVIDADE................................................................................................................................ 151
REFERÊNCIAS........................................................................................................................................ 153
X
UNIDADE 1
REVISÃO DE CONCEITOS DE
ORIENTAÇÃO A OBJETOS, REVISÃO
DE CONCEITOS DA UML, DIAGRAMAS
DE VISÃO COMPORTAMENTAL: CASOS
DE USO, DIAGRAMA DE ATIVIDADES E
DIAGRAMA DE MÁQUINA DE ESTADOS
OBJETIVOS DE APRENDIZAGEM
A partir desta unidade, você será capaz de:
• revisar conceitos de Orientação a Objetos;
• revisar conceitos de UML;
• conhecer a visão comportamental dos diagramas da UML;
• elaborar diagramas de casos de uso, de atividades e máquina de estados.
PLANO DE ESTUDOS
Esta unidade de ensino contém três tópicos. Ao final de cada um deles você
encontrará atividades que contribuirão para a apropriação dos conteúdos.
TÓPICO 1 – REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS,

REVISÃO DE CONCEITOS DA UML
TÓPICO 2 – MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML,

DIAGRAMA DE CASOS DE USO
TÓPICO 3 – DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA

DE ESTADOS
1
2
UNIDADE 1
TÓPICO 1
REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS,

REVISÃO DE CONCEITOS DA UML
1 INTRODUÇÃO
Este tópico reapresenta conceitos que são o alicerce da disciplina, bem
como os seus principais autores, conforme mostra a Figura 1.
FIGURA 1 – ORIGEM E EVOLUÇÃO DA UML

Origem e evolução da UML
1962-1963
1962 - Krysten Nygaard e Ole-Johan
Dahl, pesquisadores do Centro de
Computação da Noruega, em Oslo,
criam a linguagem Simula, derivada
do Algol, introduzindo os primeiros
conceitos de orientação a objetos.
1963 - Ivan Sutherland desenvolve,

Ivan no MIT (Massachusets Institute of Krysten
Suthorland Tecnology), nos Estados Unidos, o Nygaard
Sketchpad, primeiro editor gráfico
para desenhos orientado a objetos.
O Sketchpad usava conceitos de
instância e herança.
1969 1970 - 1983

Alan Curtis Kay apresenta sua tese É lançada linguagem de programação
de doutorado intitulada The Smaltalk, desenvolvida no centro de
Reactive Engine na Universidade pesquisas da Xerox em Palo Alto, Estados
de Utah, na qual propõe Unidos. Essa foi por muito tempo a única
uma linguagem (Flex), linguagem 100% orientada a objetos.
que contém conceitos
de orientação 1980 - Surge a linguagem de programação
a objetos. C++, que também pode ser
Alan orientada a objetos.
Curtis Kay
1983 - Jean Ichbiah cria a linguagem
ADA a pedido do Departamento
de Defesa dos Estados Unidos,
também orientada a objetos.
3
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE
VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
1985 - 1989 1990 - 1993

Bertrand Meyer lança a linguagem Peter Coad e EdYourdon lançam o livro
Eifel, orientada a objetos. Object - Oriented Analysis, também
contendo técnicas para análise e
1988 - Sally Shlaer e Stepen Mellor projetos orientados a objeto.
publicam o livro Object-Oriented
Systems Analysis: Modeling theWorld in Rebecca Wirfs - Brock, Brian Wilkerson
Data, que propõe uma técnica para e Lauren Wiener publicam o livro
análise e projetos orientados a objeto. Designing Object - Oriented Software,
Bertrand tratando de técnicas de modelagem
1989 - É criado o OMG (Object orientada a objetos.
Meyer Management Group), que aprova
padrões para aplicações orientadas 1992 - Ivar Jacobson, Magnus Christerson,
a objeto. Patrik Jonsson e Gunnar Overgaard
lançam o livro Object - Oriented
Software Enginnering:A Use Case Driven
1970 - 1983
Approach, também sobre técnicas É lançada linguagem de programação
de orientação a objetos. Smaltalk, desenvolvida no centro de
D. Embley, B. Kurtz, e S.Woodfield pesquisas da Xerox em Palo Alto, Estados
publicam o livro Object - Oriented Unidos. Essa foi por muito tempo a única James
System Analysis. A linguagem 100% orientada a objetos.
Martin
Madel-Driven Approach.
1980 - Surge a linguagem de
1993 - Grady Booch programação C++, que também pode
lança seu Booch Method ser orientada a objetos.
com técnicas para
análise e projeto 1983 - Jean Ichbiah cria a linguagem
orientado a objetos. ADA a pedido do Departamento
de Defesa dos Estados Unidos, James
também orientada a objetos. Gosling
FONTE: Piva (2010)
Este tópico foi criado com o objetivo de revisar conceitos da disciplina

de Análise Orientada a Objetos I, reapresentando os conceitos da UML, que
possibilita visualização, especificação, construção e documentação de requisitos
no desenvolvimento de software com orientação a objetos. Será exibido um
pequeno histórico da UML e principais conceitos da metodologia orientada a
objetos e sua representação na UML.
Três grandes nomes criaram a UML. Dois deles são norte-americanos:

Grady Booch e James Rumbaugh, o terceiro é o suíço Ivar Jacobson. Juntos, em
1995 lançaram a UML 0. Unificando os seus três métodos de estudos desenvolvidos
individualmente:
Método de Booch: desenvolvido por Grady Booch, da Rational Software

Corporation, expressivo principalmente nas fases de projeto e construção de
sistemas.
OOSE (Object-Oriented Software Engineering), de Ivar Jacobson, que

fornecia excelente suporte para casos de usos como forma de controlar a
captura de requisitos, a análise e o projeto de alto nível.
4
TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML
OMT (Object Modeling Technique), de James Rumbaugh, que é um método

de modelagem e projeto orientado a objetos publicado em 1991 por James
Rumbaugh, Michael Blaha, Willian Premerlani, Frederick Eddy e Willian
Lorensen, no livro Object-Oriented Modeling and Design.
FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>. Acesso em: 5 out. 2015.
Kay foi considerado o pai da orientação a objetos. Foi ele quem definiu
o computador como um organismo vivo, promovendo a independência das
células, que, mesmo independentes, deveriam se relacionar ou juntar-se a outras,
a fim de atingir um objetivo específico.
À época do surgimento da linguagem Smalltalk, Kay era pesquisador da

Xerox, e, em 1970, foi o primeiro a usar o termo “Orientação a Objetos”.
A UML oferece suporte em todas as etapas do desenvolvimento de software.

Por este motivo, atualmente é considerada um padrão de desenvolvimento
quando se utiliza da orientação a objetos.
2 ORIENTAÇÃO A OBJETOS
O objetivo da orientação a objetos é o de aproximar o desenvolvimento de
software da realidade dos acontecimentos, do fluxo real da informação. Para isso,
cria elementos e dados que tenham funcionalidades em si mesmos.
O conceito continua evoluindo, pois ainda existem limitações de hardware

que se relacionam a problemas de acesso e armazenamento de dados, e de software
relativas a processos do sistema operacional e a falta de sistemas gerenciadores
de banco de dados orientados a objetos (PIVA, 2010).
2.1 ABSTRAÇÃO
Abstração é uma característica específica da entidade, fazendo com que a
mesma se torne distinta de todas as outras entidades envolvidas em um modelo
de dados.
A abstração foca o escopo da entidade. Por exemplo, ao pensarmos na

entidade PRODUTO, não precisamos pensar em todos os atributos desta entidade.
Posso focar a atenção apenas nos atributos principais e essenciais, os quais serão a
característica desta entidade e que a tornarão exclusiva dentro de um modelo, na
análise e desenvolvimento do sistema.
5
2.2 CLASSE
Para os autores Booch, Rumbaugh e Jacobson (2005), a classe descreve
vários objetos, que juntos compartilham os mesmos atributos, operações,
relacionamentos e semântica. A representação completa de uma classe tem quatro
divisões, conforme podemos visualizar na Figura 2.
FIGURA 2 – REPRESENTAÇÃO DE UMA CLASSE

Nome da classe Definição da classe
Carro
segundo UML 2.
- nomeFabricante: String
- nomeModelo: String
- cor: String Atributos
- numeroPortas: Int
- anoFabricação: Int
- velocidadeMaxima: double
+ abrirPortas( ): vold
+ fecharPortas( ): vold
+ ligar( ): vold
+ desligar( ): vold Métodos
+ acelerar( ): vold
+ frear( ): vold
+ trocarMarcha( ): vold
Responsabilidades
- Se locomover na
velocidade e direção Responsabilidades
indicados pelo usuário.
- Acelerar quando
solicitado.
- Frear quando
solicitado.
FONTE: Piva (2010)
FIGURA 3 – OUTRA FORMA DE REPRESENTAÇÃO DE CLASSE

Outra forma de
Carro
representar uma
- nomeFabricante: String classe em UML 2.0.
- nomeModelo: String
- cor: String
Carro
- numeroPortas: Int
- anoFabricação: Int
- velocidadeMaxima: double
+ abrirPortas( ): vold
+ fecharPortas( ): vold
+ ligar( ): vold
+ desligar( ): vold
+ acelerar( ): vold
+ frear( ): vold
+ trocarMarcha( ): vold
FONTE: Piva (2010)
Nome da classe: Cada classe deve ter um nome único, que seja capaz de
diferenciar a mesma de outras classes (BOOCH; RUMBAUGH; JACOBSON, 2005).
6
Atributo: Pode ser entendido como um campo, uma propriedade que

mantém valores cujas instâncias desse atributo podem apresentar (BOOCH;
RUMBAUGH; JACOBSON, 2005).
2.2.1. Método
Para modificar o seu comportamento, um objeto da classe pode solicitar
um serviço. É algo que muda o objeto e que pode afetar todos os objetos da classe
(BOOCH; RUMBAUGH; JACOBSON, 2005). Relembre alguns dos principais
métodos, conforme descrição abaixo:
Os métodos especiais
• Construtor: é o método que constrói, isto é, reserva o espaço em memória onde

serão armazenadas as informações daquele objeto da classe.
• Get: é o método que apresenta o valor armazenado em determinado atributo
de um objeto.
• Set: dá um valor a um atributo.
Os métodos Get e Set encapsulam os atributos de uma classe, garantindo

que as alterações nos atributos sejam feitas única e exclusivamente por eles. Os
atributos permanecem com visibilidade privada. Lembrando:
Get (para retornar o valor que está no atributo).

Set (para atribuir um valor a ele).
Normalmente, no processo de desenvolvimento são adotados um método

Set e um método Get para cada atributo da classe.
• Destrutor: destrói o objeto criado da memória, liberando o espaço de memória

alocado na sua criação.
• Assinatura: é a primeira linha da definição de um método, no qual podemos
observar sua visibilidade, seu nome, seus parâmetros de entrada e de retorno.
2.2.2 Responsabilidades
As responsabilidades remetem às obrigações das classes, que, quando
criadas, estabelecem que todos os seus objetos terão o mesmo estado e tipo de
comportamento. Por isso é possível representar uma classe apenas com seu nome
ou com nome dos principais atributos e principais métodos, de acordo com o que
se quer analisar ao iniciar a criação dos diagramas.
7
2.2.3 Tipos de relacionamento entre classes

Dependência, associação e herança estabelecem os principais
relacionamentos entre as classes.
1) Dependência: determina que um objeto de uma classe possa usar as informações

e serviços de outra classe, que um objeto de uma classe use informações
e serviços de um objeto de outra classe. A dependência é representada
graficamente por uma linha tracejada com uma seta indicando o sentido da
dependência. Verifique a representação na figura a seguir. A classe Janela é
dependente da classe Evento.
FIGURA 4 – DEPENDÊNCIA DA UML

Representação de
Janela uma dependência
Evento em UML 2.0.
- largura: double
- altura: double
- nome: String
+ abrir ( ): void
+ start ( ): void
+ fechar ( ): void
+ tratarEvento ( ): void
FONTE: Piva (2010)
2) Associação: é um relacionamento de estrutura, que aponta os objetos de uma

classe que estão conectados a objetos de outra classe estrutural que especifica
objetos de uma classe conectados a objetos de outra classe. A associação é
representada por uma linha interligando as duas classes.
FIGURA 5 – ASSOCIAÇÃO ENTRE CLASSES

Exemplo de
associação entre
classes UML.
Trabalha para ►
Empresa
Funcionário
trabalhador empregador
- nome: String
- salario: double 1..* * - ramoAtividade: String
- nroCarteiraProfissional: String
- cnpj: String
FONTE: Piva (2010)
A figura a seguir apresenta um exemplo de agregação, que é um tipo de

associação entre classes na qual é mostrada a relação todo-parte entre as classes.
Uma classe é a parte, e a outra, o todo.
8
FIGURA 6 – ASSOCIAÇÃO ENTRE CLASSES
Empresa Pedido
Representação da
- nome: String - numero: Int agregação entre
- ramoAtividade: String - data: Date classes UML 2.0.
- cnpj: String - valor Total: double
1
1
*
*
ItemdePedido
Representação de
Departamento -- descrição: String uma composição
- quantidade: Int UML 2.0.
- nome: String - precoUnitario: double
FONTE: Piva (2010)
Observe, na figura anterior, que uma empresa é formada por vários

departamentos. Pode-se ver ainda que cada departamento está associado a
uma empresa.
Não podemos esquecer-nos da composição, que nada mais é do que uma

forma de agregação, tempo de vida semelhante entre as partes pelo todo. Pode-se
afirmar que numa relação de composição só faz sentido existir a parte se houver
o todo (PIVA, 2010).
3) Herança: na herança, classes mais específicas assumem a estrutura e o

comportamento de classes mais gerais. A representação da Herança pode ser
entendida pela representação da Figura 7, onde a classe Pessoa possui os atributos
nome e cpf e pode executar os métodos de andar e falar. Já a classe Funcionario
herda os atributos e métodos da classe Pessoa, possui nome, cpf, salário e
nroCarteiraProfissional, podendo executar os métodos andar, falar e trabalhar.
Logo, conclui-se que é a classe pai de Funcionario e que Funcionario é

classe filha de Pessoa.
9
FIGURA 7 – REPRESENTAÇÃO DE HERANÇA

Especialização Representação
Pessoa de herança
utilizando UML.
# nome: String
# cpf: String
+ andar ( ): void
+ falar ( ): void
Funcionario
- salario: double
- nroCarteiraProfissional: String
+ trabalhar ( ): void
Generalização
FONTE: Piva (2010)
2.2.4 Mensagem
As mensagens configuram uma forma de comunicação entre os objetos. Elas
carregam informações de uma determinada atividade que está por ser executada. Os
seja, objetos trocam informações para tornar possível o funcionamento dos sistemas.
2.2.5 Objeto
É pelo objeto que se concretiza a abstração, através de entidades bem
definidas, entidades que encapsulam estados e comportamentos; é a instância
de uma classe. Utilizando como exemplo um automóvel, podemos pensar nos
atributos como sendo: o modelo, cor, ano de fabricação, combustível, e seus
métodos como: andar, acelerar, frear, entre outros. Ao pensar nas responsabilidades
do automóvel, podemos dizer que ele deve obedecer aos comandos que lhe são
impostos, como aceleração, velocidade, trajeto etc. (PIVA, 2010).
3 PROJETO ORIENTADO A OBJETOS

Num projeto é necessário definir com precisão quais são as principais
classes que irão compor a solução para a construção de determinado software. Em
seguida, deve-se estabelecer como os objetos criados a partir dessas classes vão
interagir entre si para atingir a solução proposta em termos de desenvolvimento
de aplicação.
10
Deve-se projetar todo o funcionamento do sistema em detalhes. Um

recurso satisfatório é proposto pela UML, através do uso dos seus diagramas,
que permitem definir como funcionará cada um dos itens da solução, até, por
exemplo, em que estrutura de hardware e software será implementada e como
estarão dispostos componentes da rede envolvida na solução.
É comum, no decorrer do planejamento e desenvolvimento do projeto, o

surgimento de novas classes. Estas, geralmente, são responsáveis pela interação
do usuário com o sistema em si (PIVA, 2010). Além disso, são definidos e
protocolados todos os requisitos necessários para a segurança das informações
que serão mantidas pelo sistema. Tudo isso é possível de ser realizado mantendo-
se o uso e aplicação da UML, cujas ferramentas permitem o detalhamento de cada
um dos componentes da solução de software.
Na fase da análise do sistema (orientada a objetos) devemos concentrar

nossos esforços a fim de mapear o funcionamento e comportamento das classes
para que o sistema funcione da forma como foi projetado em termos de estrutura
de rede, software e hardware (PIVA, 2010).
4 AS VÁRIAS OPÇÕES DA UML

Segundo Piva (2010), devemos estar atentos ao que é estático e dinâmico
ao utilizarmos a UML.
Como estático podemos entender:
• definição das classes;

• modularização;
• as camadas e a configuração do hardware.
Como processo dinâmico podemos classificar as mudanças de estado que

os itens podem sofrer no decorrer da execução do software, por exemplo, pelas
alterações ocasionadas pelas trocas de mensagens entre os itens nesse momento.
Ainda de acordo com o Piva (2010) podemos perceber cinco diferentes visões
proporcionadas pela UML durante a construção de modelos de software. São elas:
• Visão de casos de uso: permite melhor compreensão do problema a ser

resolvido, ajudando na definição das fronteiras do sistema, seus principais
usuários e as principais funcionalidades a serem implementadas.
• Visão de projeto: auxilia na análise da estrutura e das funcionalidades esperadas
da solução.
• Visão de processo: também chamada de visão de interação, foca o fluxo de
controle entre os diversos componentes da solução, permitindo também
a análise de seu desempenho, a sincronização e a concorrência entre seus
componentes, necessária para o perfeito funcionamento da solução.
11
• Visão de implementação: ajuda a definir a estrutura da solução, isto é, os

arquivos de instalação, seu controle de versões.
• Visão de implantação: trata da estrutura de hardware e software, ou seja, do
ambiente em que a solução será implementada.
4.1 CONCEITOS DA ESTRUTURA DA UML

A formação da UML tem seu alicerce em três componentes básicos:
• blocos de construção;
• regras que restringem como os blocos de construção podem ser associados
entre si;
• mecanismos de uso geral, que dão mais clareza às definições criadas pelos
blocos de construção. Estes, por sua vez, são de três tipos: itens, relacionamentos
e diagramas (PIVA, 2010).
4.1.1 Itens
São as abstrações em si e a base da UML. Os itens mantêm relacionamentos,
que são mantidos pelos diagramas. Existem diferentes tipos de itens, que podem
ser classificados em quatro grupos: estruturais, comportamentais, de agrupamento
e anotacionais, que serão estudados no decorrer deste caderno.
4.1.2 Itens estruturais

São responsáveis por definir a estrutura da solução.
São formados por:
• classes;
• as interfaces;
• as colaborações;
• os casos de uso;
• os componentes;
• os artefatos;
• os nós.
Para prosseguirmos, torna-se necessário o entendimento acerca dos

elementos mencionados acima, conforme esclarecimento proposto por Piva
(2010, p. 173):
Classes: são os elementos básicos da orientação a objetos e,

consequentemente, da UML.
12
Interfaces: são as funcionalidades a serem implementadas por uma

classe ou por um componente. Demonstram o comportamento visível
de uma classe, mas nunca a implementação de tal comportamento,
pois contêm apenas a assinatura dos métodos, e sua implementação
é feita pelas classes que herdam seu comportamento. Servem para
definir comportamentos padronizados para conjuntos de classes e
itens. As interfaces são representadas por um círculo.
Colaboração: são agrupamentos de classes, relacionamentos e

interfaces que constituem uma unidade do sistema. Dizemos que
essa unidade é maior que a soma das classes e relacionamentos
implementados. São representados por uma elipse tracejada com o
nome da colaboração ao centro. A colaboração serve também para nos
dar uma visão em nível mais alto de abstração, quando não é necessário
entrar em todos os detalhes de determinado item em análise.
FIGURA 8 – COLABORAÇÃO
Controle
de Estoque
FONTE: Piva (2010)
Casos de uso: descrevem uma sequência de ações a serem executadas

pelos componentes da solução. São ativados por um ator, servem de
base para definirmos comportamentos dos elementos da solução de
software e são realizados por uma colaboração. São representados por
uma elipse com o nome da operação que implementa no centro (PIVA,
2010, p. 174).
FIGURA 9 – REPRESENTAÇÃO DE CASOS DE USO
Solicitar
Preço
FONTE: Piva (2010)
Componentes: são estruturas que instituem uma funcionalidade de

uma solução de software por meio da implementação de uma ou mais
interfaces definidas. Podem ser substituídos dentro de uma solução
por outro componente que implemente todas as suas interfaces, sem
prejuízo ao sistema como um todo (PIVA, 2010, p. 174).
13
FIGURA 10 – REPRESENTAÇÃO DE COMPONENTES
FormCliente
FONTE: Piva (2010)
Artefato: é um elemento físico do sistema, que pode ser um programa

(fonte ou executável), um script do sistema operacional e tudo o mais que pode ser
transformado em bits e bytes. É representado por um retângulo com o estereótipo
<<artefato>> e o seu nome (PIVA, 2010, p. 174).
FIGURA 11 – REPRESENTAÇÃO DE ARTEFATO
<<artefato>>
Cliente.class
FONTE: Piva (2010)
Nó: representa um recurso de computação. Pode ser um servidor,

um computador cliente, um switch, um hub etc. Qualquer elemento
computacional que faça parte da arquitetura na qual será implementada
a solução pode ser definido como um nó. Em UML é desenhado como
um cubo com seu nome dentro (PIVA, 2010, p. 174).
FIGURA 12 – REPRESENTAÇÃO DE NÓ
Servidor
FONTE: Piva (2010)
Atividade: “é um comportamento que especifica a sequência de etapas

realizadas por um processo computacional. É representada em UML por um
retângulo de vértices arredondados” (PIVA, 2010, p. 174).
imprimir
Nota Fiscal
FONTE: Piva (2010)
14
4.1.3 Itens comportamentais

São os itens que definem as partes dinâmicas dos modelos UML. São
também chamados de verbos do modelo. Constituem itens: interações, máquina
de estados e atividades.
Interações: são os conjuntos de troca de mensagens entre objetos, também

chamados de comportamento. Em UML as mensagens são representadas por
uma seta traçada sob seu nome.
Máquina de estados: “especifica os diversos estados pelos quais pode

passar um objeto ou uma interação em seu ciclo de vida. Sua definição inclui
outros componentes, como estados, transições, eventos e atividades. Em UML é
representada por um retângulo com os vértices arredondados” (PIVA, 2010, p. 174).
FIGURA 14 – REPRESENTAÇÃO DE MÁQUINA DE ESTADOS
EmEspera
FONTE: Piva (2010)
4.1.4 Itens de agrupamento

Servem para agrupar os demais itens da UML em bloco, permitindo uma
melhor organização do projeto. É composto apenas pelo item pacote (PIVA, 2010).
Pacote: “permite a inclusão de itens em seu interior para organizar o

projeto, tornando-o modular e mais organizado. É conceitual, não existindo em
tempo de execução. É representado por uma pasta, que pode receber apenas seu
nome ou a visualização dos itens que a compõem” (PIVA, 2010, p. 175).
FIGURA 15 – REPRESENTAÇÃO DE PACOTE
Controle
FONTE: Piva (2010)
15
4.1.5 Item anotacional

É o componente que permite a inserção de comentários nos modelos,
tornando-os mais claros e inteligíveis. É composto apenas pelo item nota.
Nota: tem como objetivo inserir comentários em um modelo para deixá-

lo mais compreensível. É representado por um retângulo com a ponta
superior direita dobrada para dentro. Em seu interior são inseridos
os comentários pertinentes ao que se quer explicar melhor dentro do
modelo. Também pode ser utilizada uma linha tracejada para apontar
exatamente a que ponto do modelo se destina a explicação da nota
(PIVA, 2010, p. 175).
FIGURA 16 – REPRESENTAÇÃO DE NOTA
Esta classe faz a conexão

entre o software aplicativo
e o sistema operacional.
FONTE: Piva (2010)
4.2 DIAGRAMAS
A versão 2.0 da UML traz consigo 13 diagramas, divididos em quatro
grupos:
• diagramas estruturais;
• diagramas comportamentais;
• diagramas de interação;
• diagramas de implementação.
A figura a seguir permite uma melhor visualização dos diagramas e os

grupos aos quais cada um pertence.
16
FIGURA 17 – DIAGRAMAS DA UML
Diagramas
da UML
Diagramas Diagramas
Estruturais Comportamentais
Diagrama Diagrama de
Diagrama Diagrama Casos de Uso
de Objetos de Classes de Pacotes
Diagrama
de Transições
de Estados
Diagrama de Diagrama de
Estrutura Composta Diagrama de
implementação Atividades Diagrama
de Interação
Componentes Implantação Diagrama Diagrama de Diagrama de
de Sequência Temporação Colaboração
Diagrama de Visão
Geral da Interação
FONTE: Piva (2010)
Adiante estudaremos em detalhes cada um dos diagramas apresentados.

Para facilitar nosso entendimento acerca da elaboração de cada diagrama,
precisamos estar atentos às cinco regras propostas pela UML para uma adequada
construção dos mesmos.
São elas:
• Nome: sempre devemos lembrar que o nome de um item deve deixar clara
sua formação, suas ações e responsabilidades. Não devemos nos esquecer
também de que esse nome é único dentro de um modelo.
• Escopo: todo item inserido em um modelo deve mostrar claramente quais
são seus limites, o que implementa e quando pode ser utilizado.
• Visibilidade: indica que é necessário também que fique claro quando um
item estará disponível para ser utilizado e que ações estarão disponíveis por
seu intermédio.
• Integridade: também é importante levar em conta na criação de um item a
definição clara de como este se relaciona e a consistência de tal relacionamento.
• Execução: deve estar evidente ainda o que o modelo representa e/ou simula.
O que queremos observar com a criação desse modelo.
17
As regras definem que ao inserir um item em um diagrama, você tem de

se preocupar com as características apresentadas acima, para que consiga criar
modelos bem elaborados e consistentes.
18
RESUMO DO TÓPICO 1
Neste tópico você aprendeu que:
• A UML oferece diversos subsídios para a criação de modelos claros que nos
auxiliam na construção de soluções de software de qualidade.
• A UML permite também a criação de modelos que simulam o comportamento

do software em construção em diversos aspectos. Mas nunca se esqueça: sempre
caberá ao desenvolvedor a responsabilidade de usar as informações de modo
a obter soluções de qualidade de acordo com as expectativas do usuário e que
sejam capazes de produzir os melhores resultados possíveis.
• Ao utilizar a UML precisamos de bom senso para oferecer soluções adequadas

e no prazo esperado pelo usuário, criando modelos apenas para as partes que
realmente demandam definição mais aprofundada.
19
AUTOATIVIDADE
1 Cite os objetivos da UML.
2 Defina classe.
3 Defina objeto.
4 O que você entende por pacote?
5 O que é um diagrama?
20
UNIDADE 1
TÓPICO 2
MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML,

DIAGRAMA DE CASOS DE USO
1 INTRODUÇÃO
Desenvolver um software exige do gestor do projeto a habilidade de
equilibrar pessoas, atividades, tecnologias e metodologias. Projetos de softwares
são cercados por riscos desde a sua fase embrionária. Com isso, os modelos
surgem como uma alternativa ágil para tornar a correção mais rápida e com
custo reduzido. O próprio uso de modelos já possibilita reduzir o custo do
desenvolvimento das atividades, pois permite prever o comportamento do
sistema quando o mesmo estiver finalizado e em uso.
Uma forma mais eficiente de pensar em modelagem e desenvolvimento de

projetos é a proposta orientada a objetos, que organiza os problemas em torno de
situações reais, ou seja, como elas de fato acontecem na prática, e isso impõe uma
forma completamente diferente de pensar e organizar a solução, se comparado à
forma como o pensamento estruturado apresenta a solução (BOOCH, 1994).
A grande vantagem da orientação a objetos é que os projetos são mais

facilmente compreendidos, e em consequência, mais facilmente construídos, pelos
profissionais envolvidos no projeto. A “partícula” fundamental desta metodologia
é o objeto, que traz consigo o seu comportamento, que pode vir acrescido de
regras, conhecimentos, responsabilidades e um ciclo de vida definido. Depois de
modelado não sofre modificações, sendo agregado ao que já existe no sistema. A
figura a seguir mostra as visões de um projeto orientado a objetos.
21
FIGURA 18 – VISÕES DE UM PROJETO COM UML

Workflow de Design (Arquitetura):
Desenhando Componente de Software com UML
Introdução. UML, Visões:
Visão de Visão da
Projeto Implementação
Funcionalidade Codiﬁcação
Vocabulário Montagem
Visão de
Caso de Uso
Visão do Visão da
Processo Implantação
Desempenho Topologia do Sistema
Escalabilidade Distribuição
Throughput Instalação
Conceitual Físico
FONTE: Piva (2010)
2 UML
UML significa Linguagem de Modelagem Unificada de projetos orientados
a objetos. É uma linguagem, não podendo ser considerada um método.
A UML é uma linguagem padrão de notação de projetos.
NOTA
Por notação entende-se especificar, visualizar e documentar os elementos

de um sistema OO. A UML é importante: serve como linguagem para expressar decisões
de projeto que não são óbvias ou que não podem ser deduzidas do código; provê uma
semântica que permite capturar as decisões estratégicas e táticas;provê uma forma concreta
o suficiente para a compreensão das pessoas e para ser manipulada pelas máquinas.
A UML não depende das ferramentas de programação utilizadas no

desenvolvimento do projeto.
Além de dar suporte a todos os processos de engenharia de software

necessários ao projeto, a UML pode ser definida como a linguagem de
modelagem padrão no desenvolvimento de sistemas distribuídos, por exemplo,
pois, basicamente, sua característica principal baseia-se em um conglomerado
de técnicas de notação gráfica para criar a modelagem visual dos sistemas. É
22
TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML,
uma ferramenta ágil, pois combina e suporta as melhores técnicas, que vão
desde a modelagem dos dados até o levantamento e engrenagem de todos os
componentes do sistema.
NOTA
É uma linguagem de modelagem única e atualmente muito utilizada!
A UML não tem a preocupação de demonstrar como o trabalho ou as

atividades envolvidas no projeto serão executados. O objetivo da linguagem é
descrever "o que fazer", “como fazer", "quando fazer" e "por que fazer".
A Linguagem Unificada de Modelagem utiliza diagramas que podem ser

usados de forma combinada a fim de obter todas as visões e aspectos do sistema.
3 DIAGRAMAS DA UML
Diagramas, na verdade, são gráficos que permitem visualizar o sistema de
formas diferentes. Pela notação dos diagramas da UML é possível descrever de
forma ágil e objetiva todos os aspectos da modelagem de dados, sendo que cada
diagrama tem seu significado, sua notação e a forma de ser utilizado (ANDRADE,
2007). Os diagramas da UML estão classificados em dois grupos distintos:
estruturais e comportamentais, sendo que o primeiro grupo mostra tudo o que não
muda no sistema, e o segundo mostra as reações e evoluções do mesmo.
NOTA
Cada diagrama analisa o sistema, ou parte dele, sob uma determinada ótica
(GUEDES, 2007).
A figura a seguir mostra todos os diagramas da UML agrupados de acordo

com sua classificação. Os diagramas estruturais tratam o aspecto estrutural do
ponto de vista do sistema e das classes. São para visualizar, especificar, construir e
documentar os aspectos que não são mutáveis (ANDRADE, 2007). Ainda de acordo
com o autor, os aspectos estáticos de um sistema de software envolvem a existência e
a colocação de itens como classes, interfaces, colaborações, componentes.
23

Diagramas
da UML
Diagramas Diagramas
Estruturais
FONTE: Piva (2010)

Comportamentais
24
Diagrama Diagrama de Diagrama Diagrama Diagrama Diagramas de Diagrama de
Estrutura Transições
de Objetos Implementação de Classes de Pacotes de Atividades Interação Casos de Uso
Composta de Estados
Diagrama de Diagrama de Diagrama de Diagrama de Diagrama de Diagrama de Visão

Componentes Implantação Sequência Temporização Colaboração Geral da Interação
FIGURA 19 – MODELOS DE DIAGRAMAS DA UML
Os diagramas da UML estão divididos em Estruturais e Comportamentais.
3.1 DIAGRAMAS ESTRUTURAIS

• De Classe: Este diagrama é fundamental e o mais utilizado na UML e serve
de apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de
classes com seus atributos e métodos e os relacionamentos entre classes.
• De Objeto: O Diagrama de Objeto está relacionado com o diagrama de classes
e é praticamente um complemento dele. Fornece uma visão dos valores
armazenados pelos objetos de um Diagrama de Classe em um determinado
momento da execução do processo do software.
• De Componentes: Está associado à linguagem de programação e tem por
finalidade indicar os componentes do software e seus relacionamentos.
• De Implantação: Determina as necessidades de hardware e características
físicas do sistema.
• De Pacotes: Representa os subsistemas englobados de forma a determinar
partes que o compõem.
• De Estrutura: Descreve a estrutura interna de um classificador.
3.2 DIAGRAMAS COMPORTAMENTAIS

De Caso de Uso (Use Case): Geral e informal para fases de levantamento
e análise de Requisitos do Sistema.
De Máquina de Estados: Procura acompanhar as mudanças sofridas
por um objeto dentro de um processo.
De Atividades: Descreve os passos a serem percorridos para a conclusão
de uma atividade.
De Interação: Dividem-se em:
o De Sequência: Descreve a ordem temporal em que as mensagens são

trocadas entre os objetos.
o Geral interação: Variação dos diagramas de atividades que fornece visão
geral dentro do sistema ou processo do negócio.
o De comunicação: Associado ao diagrama de Sequência, complementando-o
e concentrando-se em como os objetos estão vinculados.
o De tempo: Descreve a mudança de estado ou condição de uma instância de
uma classe ou seu papel durante o tempo.
25
TURO S
ESTUDOS FU
Cada diagrama citado acima será estudado posteriormente!
4 DIAGRAMAS COMPORTAMENTAIS
Os diagramas de comportamento têm o mesmo objetivo da modelagem
dinâmica do sistema. São usados para visualizar, especificar, construir e
documentar os aspectos do sistema que sofrem mudanças ao longo do
tempo, como, por exemplo, o fluxo de mensagens e a movimentação física de
componentes em uma rede.
FIGURA 20 – DIAGRAMAS COMPORTAMENTAIS
Diagramas
Comportamentais
Diagrama de
Diagrama de Diagrama de Diagrama de
Transições
Atividades Interação Casos de Uso
de Estados
Diagrama de Diagrama de Diagrama de Diagrama de Visão

Sequência Temporização Colaboração Geral da Interação
FONTE: Piva (2010)
Os diagramas comportamentais podem ser divididos em:
• Diagramas de Casos de Uso

• Diagrama de Atividades
• Diagrama de Máquina de Estados
• Diagramas de Interação:
o Diagrama de Sequência
o Diagrama de Comunicação
o Diagrama de Tempo
o Diagrama de Interação Geral
26
4.1 DIAGRAMA DE CASOS DE USO
NOTA
O objetivo principal deste diagrama é propor uma visão de como os usuários

interagem com o sistema.
Estes diagramas especificam o que o sistema faz, mas não detalham como
o trabalho deve ser feito.
FIGURA 21 – EXEMPLO DE DIAGRAMA DE CASO DE USO
Vender CDs
Atendente
Administrar estoque
Gerente
FONTE: Tacla (2010)
Diagrama de casos de uso é uma ferramenta de comunicação entre clientes,

usuários e desenvolvedores para discutirem e definirem as funcionalidades que
devem ser realizadas pelo sistema.
4.2 ELEMENTOS DO DIAGRAMA DE CASOS DE USO

• Atores
• Casos de uso
• Relacionamentos
• Associação
• Generalização
• Dependência: Extensão e Inclusão
27
4.3 ELEMENTO ATORES

Representam papéis desempenhados por usuários ou qualquer outra
entidade externa ao sistema, por exemplo, hardware e outros sistemas. Podem
iniciar casos de uso; podem prover e/ou receber informações dos casos de uso.
FIGURA 22 – REPRESENTAÇÃO DE ATORES
Gerente Contas Receber Scanner

FONTE: Tacla (2010)
De acordo com Tacla (2010), para encontrar os atores de um sistema deve-

se sempre examinar a situação, procurando por pessoas ou sistemas no entorno
da situação. Para esse processo ser mais eficiente deve-se questionar:
• Quais pessoas ou outras entidades interessam a um requisito funcional?

• Quem irá alimentar as informações do sistema e também quem será o receptor
destas informações?
• Quais recursos externos são utilizados pelo sistema?
• Existem pessoas que desempenham papéis diferentes no sistema?
• O sistema interage com outros sistemas que já existem e são usados pela
organização?
4.4 ELEMENTO CASOS DE USO

“A coleção de casos de uso representa todos os modos de execução do sistema
do ponto de vista do usuário. Um caso de uso é uma sequência de ações que produz
um resultado significativo (com valor) para um ator” (TACLA, 2010, p. 17).
• Quais são as tarefas de cada ator?

• Que informações o ator obtém do sistema?
• Quem as fornece?
• Quem as captura?
• Algum ator precisa ser informado sobre eventos produzidos pelo sistema?
o Sim => casos de uso de registro e notificação
• Há eventos externos que devem ser notificados ao sistema?
o Sim => deve haver casos para que os atores possam notificar o sistema
28
4.4.1 Descrição
A UML não apresenta uma descrição padrão para casos de uso, sendo
composta por diagramas informais. Vale lembrar que os diagramas de caso de
uso facilitam a visualização, mas não são descritos detalhadamente, sendo que
o uso deste diagrama apenas não é considerado suficiente para a compreensão e
modelagem total da situação (TACLA, 2010, p. 17).
De acordo com o autor, os casos de uso são facilmente descritos quando

utilizados os seguintes elementos:
• Nome
• Descrição
• Requisitos (requirements): são os requisitos funcionais providos pelo caso de uso
• Restrições (constraints), tais como pré e pós-condições e condições invariantes:
o Precondições: “define o que deve ser verdadeiro para que o caso de uso seja
iniciado. Por exemplo, num sistema bancário, para o caso de uso Abrir conta
corrente, uma precondição é apresentar CPF sem restrições (aprovação do
pedido)” (TACLA, 2010, p. 17).
o Pós-condições: “o que se torna verdadeiro pela execução do caso de uso. No
mesmo caso de uso acima, o sistema pode se encontrar em um dos seguintes
estados: conta aberta e com um depósito inicial ou conta não aberta por
reprovação do CPF” (TACLA, 2010, p. 17).
5 FLUXO DE EVENTOS
Um fluxo de evento serve para descrever como o sistema e os atores
cooperam entre si para entregar algo de valor aos atores e também descrevem
o que pode impedir que isso aconteça. Na verdade, um fluxo de eventos faz a
descrição de um caminho entre muitos, uma vez que um caso de uso pode ser
representado e executado de formas distintas (TACLA, 2010).
Ainda segundo o mesmo autor, existem fluxos distintos: fluxos primários

ou básicos e fluxo alternativo. Por esta visão, o fluxo básico se torna a explicação,
enquanto que o fluxo alternativo é a alternativa. Tomemos como exemplo a situação
proposta pelo autor citado onde uma pessoa explica um caminho para outra.
Há fluxos primários ou básicos (fluxo normal de eventos) e alternativos (o

que fazer se…). Para descrevê-los, é possível se inspirar na situação em que uma
pessoa explica um caminho a outra.
“Para ir ao churrasco, pegue a BR-116 na direção de São Paulo. Logo após o

Clube Santa Mônica, tem um retorno por baixo da pista. Faça o retorno e continue reto
(não retorne à BR). Continue nesta estradinha asfaltada por 1 km, no entroncamento
pegue a estrada de terra à direita, ande cerca de 500m, você verá um grande eucalipto
29
e uma araucária. A entrada da chácara é entre os dois. Não se esqueça de trazer o

pinhão” (TACLA, 2010, p. 18) // EXEMPLO DE FLUXO PRIMÁRIO
“Se estiver chovendo muito, os 500m na terra podem ser bem difíceis,
porque o barro é mole. Neste caso, siga reto no entroncamento (ao invés de virar
à direita) e na próxima à direita pegue a rua de paralelepípedos. Ande cerca de 1
km e depois vire na segunda à direita que vai desembocar na frente da chácara”
(TACLA, 2010, p. 18) // EXEMPLO DE FLUXO ALTERNATIVO 1
“Se você for comprar o pinhão no caminho, logo depois de fazer o retorno
da BR tem uma venda. Se estiver fechada, um pouco mais à frente tem um
senhor da Chácara Pinhais que também vende. Se não encontrar pinhão, não tem
problema” (TACLA, 2010, p. 18) // EXEMPLO DE FLUXO ALTERNATIVO 2
Tacla (2010) sugere que nas fases iniciais de análise dos dados é importante
manter o foco nos fluxos básicos, pois 80% do tempo de execução de um sistema são
ocupados por casos primários. Mas não devemos nos esquecer de documentar os
fluxos alternativos, uma vez que ambos documentam como as responsabilidades
especificadas nos casos de uso são divididas entre sistema e atores.
E
IMPORTANT
“No desenrolar do projeto, as responsabilidades atribuídas ao sistema devem ser

distribuídas entre os objetos que compõem o sistema” (TACLA, 2010, p. 19).
5.1 FLUXO BÁSICO

Um fluxo básico demonstra o que acontece quando se executa o caso de
uso. Para que isso seja possível, o mesmo deve conter o ator e o evento disparado
para dar início ao caso; a iteração entre o ator e o sistema e a descrição de como o
caso é finalizado.
5.2 SUBFLUXO
NOTA
Para melhor entendimento de um fluxo, este pode ser fragmentado em vários

subfluxos.
30
“Um fluxo de eventos pode ser decomposto em subfluxos para melhorar

a legibilidade. Importante evitar muitas decomposições para não dificultar o
entendimento. Os subfluxos devem ser executados na totalidade, não podem ser
executados pela metade” (TACLA, 2010, p. 19).
5.2.1 Pontos de extensão

São pontos específicos do fluxo que permitem inserir comportamentos
adicionais. Podem ser privados ou públicos (TACLA, 2010, p. 20).
NOTA
Privados: caso sejam visíveis somente dentro do caso de uso onde foram criados.
Públicos: quando estendem o caso onde foram definidos.
No exemplo Buscar produtos e fazer pedido, os pontos de extensão

seguintes são encontrados (TACLA, 2010, p. 20):
_ {Mostrar catálogo de produtos}

_ {Escolher produto}
_ {Produto esgotado}
_ {Processar pedido}
_ {Informações de pagamento não válidas}
_ {Informações de envio não válidas}
Um ponto de extensão pode definir:

• uma localização única dentro do fluxo, por exemplo, {Mostrar
catálogo de produtos}, {Escolher produtos} e {Processar pedido};
• um conjunto de localizações que representam um certo estado do
caso de uso, por exemplo, {Produto esgotado} que poderia aparecer
em vários pontos do fluxo de eventos;
• uma região entre dois pontos de extensão, por exemplo, {Escolher
produtos} e {Processar pedido} (TACLA, 2010, p. 20).
5.3 FLUXO ALTERNATIVO

“Um fluxo alternativo apresenta um comportamento opcional, de outra
forma, que não é parte do comportamento normal de um caso de uso” (TACLA,
2010, p. 21). Fluxos alternativos são fluxos que podem ser executados numa
funcionalidade a partir de escolha do usuário, e não de erros do sistema. São três
tipos de fluxos alternativos:
31
• Específico: iniciam num ponto de extensão.

• Regional: podem ocorrer entre dois pontos de extensão.
• Geral: podem ocorrer em qualquer ponto do caso de uso.
6 ELEMENTO RELAÇÕES
São várias as relações em Casos de Uso, mas as mesmas não representam
a ordem de execução dos casos. E as mesmas devem melhorar a compreensão
daquilo que o sistema deve executar.
6.1 ASSOCIAÇÃO
Associação é a mais comum das relações. Pode ser percebida entre dois
atores ou entre um ator e um caso de uso. São representadas por uma linha cheia,
com ou sem direção.
6.2 ATOR X ATOR

Relações associativas podem conectar atores para representar
comunicação entre atores. A relação pode receber um nome que
identifica o conteúdo da mensagem, documento ou objeto que trafega
entre os atores. A figura mostra uma associação entre o ator usuário de
biblioteca que passa o livro ao atendente que realiza o empréstimo ou
a devolução. Como não há flechas, assume-se que o atendente devolve
algo ao usuário da biblioteca, provavelmente um comprovante não
representado no diagrama. Não é recomendável colocar este tipo de
relação no diagrama de casos de uso (TACLA, 2010, p. 22).
FIGURA 23 – REPRESENTAÇÃO DE RELAÇÕES EM CASOS DE USO
Realizar Empréstimo
livro
Realizar Devolução
Usuário Biblioteca Atendente
FONTE: Tacla (2010)
6.3 ATOR X CASO

Associações entre atores e casos de uso servem para indicar se quem
dá início à comunicação é o ator ou o caso de uso, além de traçar o fluxo da
informação, indicando quem alimenta quem com a informação.
32
6.4 ELEMENTO DEPENDÊNCIA - INCLUSÃO E EXTENSÃO

Quando um caso de uso inclui outro caso de uso (considerado um
subcaso) na sua execução, este está usando a relação de inclusão entre casos
de uso. Um subcaso pode ser considerado como um subfluxo de um fluxo de
eventos primário, que foi separado e deve ser executado por completo. A Figura
24 mostra:
Um caso onde se efetua uma matrícula que possui subfluxos escolher

disciplinas, alocar alunos às turmas e emitir boleto. Este último é
compartilhado com o caso Efetuar inscrição curso opcional e, portanto,
deve ser representado no diagrama. Um erro comum que adiciona
complexidade ao diagrama é incluir os subfluxos escolher disciplinas
e alocar alunos às turmas no diagrama (TACLA, 2010, p. 22).
FIGURA 24 – RELAÇÃO DE INCLUSÃO
Efetuar inscrição Curso Opcional
<<Include>>
Emitir Boleto
Alocar Alunos as Turmas
<<Include>>
Aluno <<Include>>
Efetuar Matrícula
<<Include>>
Escolher Disciplinas
FONTE: Tacla (2010)
NOTA
A inclusão deve ser utilizada para administrar comportamentos comuns e não

para estruturar funcionalmente o diagrama.
33
7 EXTENSÃO
É uma indicação de que outros casos de uso poderão ser adicionados a um
caso de uso específico. Para Tacla (2010, p. 25):
• Um caso de uso de extensão não requer modificações no caso base

(aquele que é estendido). O comportamento básico do caso base
permanece intacto. Um caso de uso que estende um caso base conhece
este último (não é muito comum um caso de uso estender mais de um
caso base).
• Uma extensão nasce como um fluxo alternativo, mas nem todo fluxo
alternativo vira uma extensão.
• vCasos de uso que estendem assumem o controle no ponto de
extensão e quando terminam devolvem o controle no mesmo ponto.
Pelo exemplo proposto na Figura 25, “a emissão de histórico escolar

é estendida pelo caso imprimir comprovante de término quando o
aluno solicitante for formado. Observa-se que é um comportamento
opcional que pode não ser oferecido sem prejuízo ao comportamento
básico emitir histórico escolar” (TACLA, 2010, p. 26).
FIGURA 25 – EXEMPLO DE EXTENSÃO
Emitir Historico Escolar
values
aluno formado aluno formado e um
Aluno ponto de extensão
<<extend>>
Imprimir Comprovante Termino
FONTE: Tacla (2010)
Nota-se no ponto de extensão público denominado {aluno formado}

onde o comportamento opcional imprimir comprovante término é
inserido. É provável que existam outros pontos de extensão privados
definidos nos fluxos de emitir histórico escolar, porém, no diagrama
só os usados pelas extensões são listados (TACLA, 2010, p. 26).
8 ELEMENTO GENERALIZAÇÃO/ESPECIALIZAÇÃO
A relação de generalização/especialização pode ocorrer entre casos de uso
ou entre atores.
Caso x Caso
34
Generalização permite especificar comportamentos genéricos que

podem ser especializados para atender necessidades específicas. Normalmente
é utilizado quando se quer descrever famílias de sistemas. Por exemplo, uma
empresa que desenvolve software para terminais bancários de autoatendimento
quer expandir seus negócios para outras áreas, tais como pagamento direto
em bombas de gasolina.
NOME: Realizar transação (caso abstrato).

DESCRIÇÃO: Permite ao usuário comprar mercadorias de um terminal
automático, sendo o valor das mercadorias descontado de uma conta bancária.
PRECONDIÇÕES: (e) O cliente possui um cartão bancário; a conexão com o
banco está ativa; o terminal deve ter mercadoria.
PÓS-CONDIÇÕES: (ou) O terminal retornou o cartão bancário ao cliente,
entregou a mercadoria ao cliente e debitou o valor de sua conta. O terminal
retornou o cartão bancário ao cliente, não entregou nenhuma mercadoria e
nenhum valor foi debitado da sua conta.
FONTE: Disponível em: <https://www.passeidireto.com/arquivo/6299813/analise-e-projeto-oo-e-
uml/8>. Acesso em: nov. 2015.
Ator x Ator
Especialização de atores representa que um conjunto deles possui

responsabilidades ou características em comum. Algumas dicas para evitar
modelagens desnecessárias:
• Não utilizar atores para representar permissões de acesso.

• Não utilizar atores para representar organogramas (hierarquias) de cargos
de uma empresa.
• Utilizar atores somente para definir papéis em relação ao sistema.
Por exemplo, se num sistema de matrículas de uma universidade há

casos de usos especiais para alunos de ciências exatas e para alunos de humanas,
então é sinal de que estes alunos são especializações de um ator genérico aluno.
A Figura 26 ilustra a notação UML para este caso. Observar que alunos de
ciências exatas e de humanas herdam todas as associações do ator aluno.

35
Aluno
Aluno C. Extas Aluno Humanas

FONTE: Tacla (2010)
9 DICAS IMPORTANTES
Casos de uso auxiliares
“Casos de uso auxiliares são frequentemente esquecidos, pois não são

essenciais à funcionalidade do sistema. Porém, esquecê-los completamente pode
conduzir a um sistema difícil de ser utilizado” (TACLA, 2010, p. 27).
“Lembrar de colocar casos de uso para executar, manter e configurar o

sistema, tais como: lançar e parar o sistema, incluir novos usuários, fazer backup das
informações, incluir novos relatórios e realizar configurações” (TACLA, 2010, p. 27).
Decomposição funcional
Tacla (2010, p. 28) explica a decomposição funcional desta forma:
• Não é necessário detalhar em excesso os casos de uso. Muitos

detalhes levam à decomposição dos casos em funções. O objetivo é
compreender o sistema através de cenários de utilização.
• Casos de uso não são feitos para analisar (no sentido de decompor)
os requisitos em requisitos menores. É um processo de síntese ou
elaboração (e não de análise) no qual o problema não é totalmente
conhecido. Quebrá-lo em partes menores (análise) dificulta a obtenção
de uma visão geral.
• Em equipes com forte competência em análise estruturada, há
tendência em encontrar funções ao invés de casos de uso. Por exemplo,
fazer pedido, revisar pedido, cancelar pedido e atender pedido
podem parecer bons casos de uso. No fundo, todas estas funções estão
relacionadas ao caso de uso realizar pedido.
• Decomposição funcional pode levar a um número intratável de casos,
mesmo para pequenos sistemas, e à perda de foco no que realmente é
importante no sistema (o que traz valor aos atores).
• Casos de uso não chamam outros casos de uso ou se comunicam
com outros casos.
36
Estrutura e detalhamento
Ainda de acordo com Tacla (2010, p. 30):
• Não estruturar demais o diagrama de casos de uso, isto é, não

inclua relações entre casos de uso a não ser que sejam extremamente
necessárias. O uso em excesso destas relações pode fragmentar o
diagrama, diminuindo a compreensão global.
• O modelo deve ser o mais simples e direto possível.
• Não descrever o que ocorre fora do sistema. Por exemplo, interação
entre atores pode ser importante para o negócio, mas se o sistema não
facilita esta interação, deixe-a fora. Se for necessário esclarecer estes
pontos, faça um modelo do negócio e não um modelo de casos de uso.
• Não fazer casos tais como incluir, consultar, alterar e excluir (ICAE).
Casos de uso que descrevem comportamentos ICAE não adicionam
muito valor à descrição da funcionalidade do sistema. Para estes tipos
de comportamentos, os requisitos são bastante claros e não se deve
perder tempo especificando-os.
Modelo de casos de uso é mais que um diagrama
O diagrama de casos de uso é uma visão panorâmica dos casos de uso e,

portanto, apenas um dos componentes do modelo de casos de uso. A descrição
textual dos mesmos é a parte mais importante do modelo. São elementos
do modelo de casos de uso: glossário, modelo do domínio e diagramas de
atividades.
Um glossário e um modelo do domínio podem evitar o excesso de

detalhes nas descrições dos casos de uso. Por exemplo, ao invés de descrever
a validação da entrada de dados, os campos podem ser definidos no glossário
com os respectivos valores possíveis.
Um modelo do domínio ajuda a entender as relações existentes entre as

entidades do domínio e as restrições sobre as relações.
37
Passos
Para elaborar um modelo de casos de uso, os seguintes passos podem ser

seguidos (TACLA, 2010, p. 35):
• Recapitular a visão do sistema (estudo de viabilidade) aos envolvidos.

• Elaborar, se necessário, um diagrama de contexto para definir os
limites do sistema (o que está dentro e o que está fora).
• Identificar os atores do sistema.
• Identificar os casos de uso: descrevê-los e rascunhar o fluxo de
eventos. Não se preocupe com fluxos alternativos. Não gaste mais do
que 10 minutos para descrever cada caso de uso.
• Esboçar o diagrama de casos de uso mostrando associações entre
atores e casos de uso.
• Verificar os casos de uso.
• Há casos de uso sem conexão com requisitos funcionais? Caso haja,
pode haver casos em excesso ou requisitos que não foram identificados!
• Há requisitos funcionais sem casos? Alguns casos podem ter sido
esquecidos.
• Todos os requisitos não funcionais foram tratados (associados aos
casos de uso quando são específicos)?
• Todos os tipos de usuários foram mapeados para um ator ao menos?
• Descrever os casos detalhadamente.
• Representar os subfluxos (<<include>>) e fluxos alternativos
(<<extend>>) considerados importantes no diagrama.
• É possível eliminar os casos incluídos ou as extensões e ainda ser
capaz de entender o que o sistema faz para as partes interessadas?
38
RESUMO DO TÓPICO 2
Neste tópico você viu que:
• Todos os diagramas da UML são úteis para análise de aspectos importantes do

desenvolvimento de software, mas não é necessário aplicar todos os diagramas
em um mesmo projeto. Escolha apenas aqueles que o ajudarão a entender
melhor o sistema que está desenvolvendo e a deixar mais claras as soluções
que irá implementar.
• Não deve deixar que os diagramas fiquem grandes e complexos demais.
• Se perceber que isso está acontecendo, tente separá-los em mais de um,

dividindo suas funcionalidades.
• Normalmente, todos os diagramas são desenvolvidos com auxílio de um

software.
• Diagrama de casos de uso é um diagrama que mostra um conjunto de casos

de uso, atores e seus relacionamentos. Abrange a visão estática de caso de uso
de um sistema, ele é criado após o levantamento dos requisitos da solução
imaginada, cada caso de uso é um de seus requisitos funcionais.
• Este diagrama permite visualizar os limites do sistema, sua relação com os

demais sistemas, com seus componentes internos e as funções que deve realizar.
39
AUTOATIVIDADE
1 Explique a utilidade do diagrama de casos de uso para os testes do sistema.
2 Explique a utilidade do diagrama de casos de uso para criação dos manuais

do usuário.
3 Construa um modelo de casos de uso para a seguinte situação fictícia:

“Estamos criando um serviço de entregas. Nossos clientes podem nos
requisitar a entrega de volumes. Alguns volumes são considerados de maior
valor por nossos clientes, e, portanto, eles querem ter tais volumes segurados
durante o transporte. Contratamos uma companhia de seguro para segurar
volumes de valor”.
FONTE: Disponível em: <http://ebrito.com.br/profa-elaine/ExGabarito.pdf>. Acesso em: 20
out. 2015.
4 Qual é a notação da UML para um caso de uso? Qual é a notação da UML

para um ator? Qual a notação utilizada na UML para o relacionamento de
generalização entre casos de uso?

out. 2015.
5 Defina o que significa um ator. O que significa um ator estar associado a um

caso de uso por um relacionamento de comunicação?
out. 2015.
6 Qual o objetivo dos casos de uso?
7 Considere a seguinte declaração obtida de um gerente de uma empresa

que comercializa livros por correio durante o levantamento de requisitos
para construção de um sistema de software: “Após a ordem de compra do
cliente ter sido registrada, o vendedor envia uma requisição ao depósito
com detalhes da ordem de compra”. Quais atores em potencial podem ser
identificados a partir desse texto?
out. 2015.
40
8 Em uma empresa, vários projetos são realizados. Os 50 empregados da
empresa trabalham em pelos menos um projeto. Há um sistema implantado
na empresa que permite aos participantes de um determinado projeto
marcarem suas horas de trabalho. Esse sistema também permite que outra
pessoa, ao fim do mês, gere os relatórios com os totais de horas trabalhadas
de cada participante. Quantos atores você definiria para esse sistema?
out. 2015.
9 Suponha que um sistema de vendas deve gerar de forma automática um

conjunto de estatísticas para a diretoria da empresa no último dia útil de
cada mês. Desenhe o diagrama de casos de uso para essa situação.

out. 2015.
41
42
UNIDADE 1
TÓPICO 3
DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE

ESTADOS
1 INTRODUÇÃO
O diagrama de atividades é um gráfico de fluxo e mostra basicamente o
fluxo de controle de uma atividade para outra, sendo utilizado para modelar o
comportamento dos processos. É um dos diagramas que mais sofreu alterações
desde o surgimento da UML, e abrange a visão dinâmica da UML (modela
situações que sofrem mudanças no sistema). Neste diagrama, uma atividade é
modelada através de uma sequência estruturada de ações sendo controladas, na
maioria das vezes, por nós de decisão.
Veja na Figura 27 o exemplo do diagrama de atividades gerado pelo caso

de uso Registrar compra produtos, proposto por Piva (2010).
43
FIGURA 27 – DIAGRAMA DE ATIVIDADES

Funcionário Sistema Diagrama de atividades
do caso de uso Registrar
compra produtos.
Verificar
Login,
Senha
login inválido
Logar no
sistema Funcionário
login válido Verificar

Cartão do
Solicitar
Cliente
cartão do
Cliente
Cartão
Passar
código da
Verificar
Barra do
cartão inválido Existência
cartão do
do Produto Produto
cliente
cartão válido
Passar não existe

código da
Barra do
Produto
existe Verificar
Digitar a Saldo do
ItemCompra
quantidade Produto
comprada
do Produto não possui saldo suficiente
possui saldo suficiente

Atualizar
não existe
total da
empresa
Criar
Terminar Compra
registro do
Produto existe
Compra
FONTE: Piva (2010)
O diagrama de atividades apresenta de forma simples e clara as ações que

são executadas em cada caso de uso. Este tipo de diagrama deve ser dividido com
linhas verticais para identificar o executor da ação.
44
TÓPICO 3 | DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
2 AÇÃO
Uma ação é uma ação que não pode ser decomposta dentro de uma
atividade. Já uma atividade é representada por ações ou subatividades. Uma
ação não inicia sua execução até que todas as suas condições de entrada sejam
satisfeitas. Somente quando uma ação é terminada é que a ação subsequente
fica habilitada.
NOTA
Ações também podem ser entendidas como precondições, que irão definir
condições necessárias para que uma ação possa ser executada, e também pós-condições
que vão definir o estado depois que a ação for executada.
3 ATIVIDADES
Atividades podem ser representadas por sequências de ações e
também de subatividades. Dessa forma, para representar uma
subatividade dentro de uma atividade (ou seja, todo um conjunto de
ações ou subatividades), utiliza-se uma representação semelhante à de
uma ação, com um pequeno ícone no canto direito inferior. Disponível
em: <www.dca.fee.unicamp.br/~gudwin/ftp/ea976/AtEst.pdf>. Acesso
em: nov. 2015.
4 EVENTOS
São situações onde ocorrem mudanças de estado de forma muito rápidas
e estabelecem o início de outra ação.
5 NÓS DE CONTROLE
Nós de controle existem para controlar o fluxo dos processos e os dados
entre as ações.
6 PONTOS DE EXTENSÃO
Evitam que o diagrama fique muito poluído, pois permitem a partição das
ações.
45
FIGURA 28 – EXTENSÕES
Usuário Sistema
Sistema na
tela principal
Seleciona Opção
"Pagamento de
Contas "
Abre Janela
"Pagamento
de Contas"
Seleciona
opção
[opção = continua]
[opção = cancela]
Abre Janela
Insere de password
Dados
Solicita
cancelamento
Clica OK
Limpa tela
de password
Seleciona [result - incorreto]

opção
Verifica
password
[opção - continua]
[opção - cancela] [result - correto]
Insere
password Efetua
pagamento
Solicita Fecha tela
da conta
cancelamento de password
Fecha tela de
pagamento
de contas
FONTE: Piva (2010)
Diagramas de atividade como os da figura são utilizados para detalhar

os casos de uso levantados durante a especificação do sistema. Nesses
diagramas, assume-se que o usuário do sistema realiza certas ações
e o sistema, em resposta, reage realizando certas tarefas. Com isso, o
comportamento do sistema pode ser especificado (PIVA, 2010, p. 191).
46
7 OUTROS RECURSOS EM DIAGRAMAS DE ATIVIDADES
Os diagramas de atividades possuem ainda, de acordo com a versão 2.3

da norma UML, outros recursos não apresentados aqui neste texto, que podem
elevar sobremaneira a complexidade do diagrama. Dentre eles, o recurso de
regiões de expansão, os pinos de entrada e saída, os nós estruturados, os
conjuntos de parâmetros e outros podem ser consultados diretamente no texto
da norma.
Um diagrama de atividades mostra um processo de negócios

ou um software como um fluxo de trabalho por meio de uma série de
ações. Computadores, componentes de software ou as pessoas podem executar
essas ações.
Você pode usar um diagrama de atividades para descrever processos

de diversos tipos, como os exemplos a seguir:
Um processo de negócios ou um fluxo de trabalho entre usuários e
seu sistema. Para obter mais informações, consulte Requisitos de usuário do
modelo.
As etapas executadas em um caso de uso. Para obter mais informações,
consulte Diagramas de caso de uso UML: diretrizes.
Um protocolo de software, ou seja, as sequências permitidas de
interações entre os componentes.
Um algoritmo de software.
FONTE: Disponível em: <https://msdn.microsoft.com/pt-br/library/dd409360.aspx>. Acesso em:

30 set. 2015.
8 RELAÇÃO COM OUTROS DIAGRAMAS

Se você desenhar um diagrama de atividades para descrever um
processo comercial ou uma forma em que os usuários poderão usar seu
sistema, você pode desenhar um diagrama de caso de uso para mostrar uma
exibição diferente das mesmas informações. No diagrama de caso de uso você
pode desenhar as ações dos casos de uso. Dê aos casos de uso os mesmos
nomes que as ações correspondentes. As vantagens da exibição de caso de uso
é que você pode:
• Mostrar em um diagrama como maiores ações/casos de uso são compostos

de pequenos, usando a relação inclui.
• Conecte cada caso de uso/ação explicitamente para os usuários ou sistemas
externos envolvidos em sua execução.
• Desenhe limites em torno de ações/casos de uso com suporte pelo seu
sistema ou cada componente principal.
47
Você também pode desenhar um diagrama de atividades para

descrever o design detalhado de uma operação de software.
Em um diagrama de atividades você pode mostrar o fluxo de dados

passados entre ações. Consulte descrevendo o fluxo de dados. Mas um diagrama
de atividades não descreve a estrutura dos dados. Para essa finalidade, você
pode desenhar um diagrama de classe UML.
Para modelar processos/atividades, a UML (Unified Modeling Language)

sugere a utilização do Diagrama de Atividades, que descreve os passos a serem
percorridos para a conclusão de uma determinada situação.
FONTE: Disponível em: <http://www.purainfo.com.br/artigos/uml-diagrama-de-atividades/>. Acesso

em: 30 set. 2015.
Para fluxos simples: Você pode demonstrar uma sequência de atividades

com tomada de decisão, como, por exemplo:
FIGURA 29 – FLUXOS SIMPLES
1
Início
Receber nº da conta
2
Pesquisar conta
Emitir mensagem
3 Conta existe?
(Não) de conta válida
4
(Sim)
Emitir mensagem
de conta válida
5
Fim
FONTE: Piva (2010)
9 EXEMPLO DE CRIAÇÃO DE DIAGRAMA DE ATIVIDADES

Exemplo 1: Considere o fluxo de trabalho associado à construção de
uma casa. Primeiro, você seleciona um local. A seguir, contrata um arquiteto
para projetar sua casa. Uma vez definida a planta, seu desenvolvedor
48
determina os custos da casa. Após concordar com um preço e com uma forma
de pagamento, a construção pode começar. As licenças são tiradas, o terreno
é cavado, a fundação é cimentada, as estruturas são erguidas e assim por
diante, até tudo ficar pronto. Você então recebe as chaves e um certificado de
“habite-se” e toma posse da casa. Embora seja uma grande simplificação do
que realmente acontece em um processo de construção, essa descrição capta o
percurso crítico do fluxo de trabalho correspondente.
FONTE: Disponível em: <http://www.purainfo.com.br/artigos/uml-diagrama-de-atividades/>. Acesso

em: 30 set. 2015.
FIGURA 30 – DIAGRAMA DE ATIVIDADES
Estado inicial
Estado de Ação Selecionar local
Contratar arquiteto
Desenvolver plano
Orçar plano
[rejeitado]
[else] Bifurcação concorrente
Fazer trabalho no local Fazer trabalho com Estado da atividade

outros setores com submáquina
União concorrente
CertificadoDeHabitse
Construir construção
[Concluído]
Estado final Fluxo de objetos
FONTE: Disponível em: <http://www.purainfo.com.br/artigos/uml-diagrama-de-atividades/>.

Acesso em: 5 set. 2015.
49
Características:
• Um diagrama de atividades é essencialmente um fluxograma que dá ênfase

à atividade que ocorre ao longo do tempo.
• Você pode considerar um diagrama de atividades como um diagrama de
sequência cujo interior é revelado.
• Um diagrama de sequência observa os objetos que passam mensagens.
• Um diagrama de atividades observa as operações passadas entre os objetos.
• Mostra o fluxo de uma atividade para outra.
• Uma atividade é uma execução em andamento.
• As atividades resultam em uma ação.
• As ações abrangem a chamada a outras operações, enviando um sinal,
criando ou destruindo um objeto.
Exemplo 2: O diagrama a seguir mostra um diagrama de atividades

para uma empresa de varejo, que especifica o fluxo de trabalho envolvido
quando um cliente devolve um item de um pedido postal. O trabalho
começa com a ação solicitar devolução do cliente e depois flui por televendas
(receber número de devolução), retorna ao cliente (enviar item) e, a seguir, ao
depósito (receber item e depois Incluir item novamente no estoque) e, por fim,
terminando em contabilidade (creditar conta). Conforme o diagrama indica,
um objeto significativo (i, uma instância de Item) também acompanha o fluxo
do processo, mudando do estado devolvido para o estado disponível.
FONTE: Disponível em: <www.purainfo.com.br/artigos/uml-diagrama-de-atividades>. Acesso em:

29 set. 2015.
50
FIGURA 31 – EXEMPLO 2 – DIAGRAMA DE ATIVIDADES
Informa novo
código do Cliente
Verifica se o
cliente já existe
[Cliente Não existe] Informa os dados Salva dados

do novo cliente do cliente
[Cliente já existe]
Exibe mensagem
ao usuário
FONTE: Disponível em: <www.purainfo.com.br/artigos/uml-diagrama-de-atividades>.

Acesso em: 10 set. 2015.
Diagrama de máquina de estados: Esboça a visão dinâmica de um sistema

(TACLA, 2010).
Principais componentes: estado, evento.
Esse diagrama mostra os estados que podem ser assumidos por um

objeto em seu ciclo de vida. Geralmente o utilizamos para entender
como tais mudanças acontecem, de modo a podermos definir as trocas
de mensagens e os métodos que as controlam. O início da transição
é representado por um círculo preenchido, e o final por um círculo
preenchido, porém com um aro pintado de branco (PIVA, 2010, p. 193).
Utilizando o exemplo proposto pelo autor, atentemos para a situação

da classe Produto da padaria do senhor João, que pode assumir três estados
diferentes: 1 Ativo, 2 Ponto de encomenda e 3 Em falta. Esses valores são aplicados
ao atributo situação quando a execução do caso de uso Registrar pagamento
compra ou do caso de uso Registrar entrada de produtos.
51
FIGURA 32 - EXEMPLO DE DIAGRAMA DE MÁQUINA DE ESTADOS

Produto
recebeProduto( )
Variação do atributo situação quantidadeEstoque+quantidadeEntrada>pontoEncomenda
recebeProduto( )
quantidadeEstoque+quantidadeEntrada>pontoEncomenda
Ativo(I) Ponto de encomenda (2)
pagaCompra( )
quantidadeEstoque<=pontoEncomenda
pagaCompra( )
quantidadeEstoque - - 0
Em falta (3)
recebeProduto( )
quantidadeEstoque<=pontoEncomenda
FONTE: Piva (2010)
Pelo diagrama podemos perceber que, através de um estado ativo,

o produto poderá mudar sua situação para “ENCOMENDA” ou
“EM FALTA”, dependendo das suas saídas, sendo que a regra
estabelecida para a situação de encomenda é seu saldo ser menor que
o indicado para este campo. Observe também que somente os métodos
pagarCompra e receberProduto alteram o estado do produto e que a
baixa do estoque só se concretiza quando o pagamento da compra é
efetivado (PIVA, 2010, p. 194).
52
LEITURA COMPLEMENTAR
Usando a modelagem colaborativa no aprendizado da UML
Mauro C. Pichiliani1, Celso M. Hirata1 1

Divisão de Ciência da Computação – Instituto Tecnológico de
Aeronáutica (ITA)
Caixa Postal 12.228-900 - São José dos Campos - SP
{pichilia, hirata}@ita.br
Abstract. The design is an important task in the object-oriented software

development. Collaborative tools has been considered to be used in software development,
however little effort has been made in the assessment of usage of these tools for both
productivity verification and ef ectiveness of collaborative learning. For the assessment
of the effectiveness of collaborative learning, it is required the data collection for analysis.
This article describes a study of data collection for the assessment of the effectiveness of
learning of students groups where a collaborative tool was used to assist the learning
of UML.
Resumo. O projeto é uma tarefa importante no desenvolvimento de

software orientado a objetos. Ferramentas colaborativas têm sido consideradas
para serem utilizadas no desenvolvimento de software, contudo, pouco esforço
tem sido feito na avaliação do uso dessas ferramentas tanto para a verificação de
produtividade quanto para a eficácia do aprendizado colaborativo. Para avaliação
da eficácia do aprendizado colaborativo existe uma necessidade de obtenção de
dados para a análise. O presente artigo descreve um estudo da coleta de dados
para a avaliação da eficácia do aprendizado de grupos de alunos onde uma
ferramenta colaborativa foi empregada para auxiliar o aprendizado da UML.
1 INTRODUÇÃO
A área de Informática na Escola tem evoluído muito nessa década,

principalmente pelo uso de ferramentas de groupware pedagógicas que exploram
o uso de colaboração no aprendizado. De acordo com Stahl [STAHL, 2002], o uso
de ferramentas de groupware na escola pode facilitar, dentre outras habilidades, o
aprendizado colaborativo e a construção do conhecimento. Contudo, pouco esforço
tem sido feito no sentido de avaliar quantitativamente a eficácia e produtividade
do aprendizado dos alunos que utilizaram ferramentas colaborativas como
instrumento pedagógico.
Uma das maneiras de acompanhar a evolução do aprendizado de

alunos que utilizam ferramentas colaborativas no aprendizado é analisar o
aproveitamento dos estudantes por meio do histórico das interações dos alunos
entre si e com o ambiente. O objetivo deste artigo é propor o uso de coleta de
dados e uma alternativa de avaliação do aprendizado de grupos de alunos
53
quando uma ferramenta colaborativa é empregada como instrumento pedagógico

no aprendizado da UML (Unified Modeling Language) (BOOCH, 1998), por meio
da análise do histórico das interações geradas durante o aprendizado. Neste
contexto, este artigo apresenta uma análise das variáveis de coleta de dados do
aprendizado de grupos de alunos em um experimento controlado.
A partir desta análise dos dados coletados, o professor poderá dispor de

um acompanhamento mais preciso do que o grupo realmente está aprendendo,
assim como uma visão geral do processo ensino-aprendizagem. Este artigo está
dividido em cinco seções.
A Seção 2 descreve uma visão geral dos aspectos funcionais das ferramentas
colaborativas e algumas abordagens de avaliação disponíveis na literatura. Na
Seção 3 apresentam-se detalhes do grupo de alunos e do experimento realizado. Na
Seção 4 apresenta-se uma alternativa de avaliação da eficácia de aprendizado dos
grupos usando informações coletadas durante o uso da ferramenta colaborativa.
Por fim, na Seção 5 são apresentadas algumas considerações finais.
2 FERRAMENTAS COLABORATIVAS
Uma ferramenta colaborativa que será empregada para auxiliar o ensino

de algum conteúdo deve levar em consideração alguns aspectos funcionais
para poder suportar a colaboração. Santoro et al. (2002) citam como principais
aspectos funcionais a comunicação, a coordenação, a percepção (awareness), o
compartilhamento de informações e a designação de papéis. A comunicação é de
extrema importância em situações de trabalho em grupo, seja ela utilizada para
trocar ideias, discutir, aprender, negociar ou para tomar decisões.
A comunicação pode ser classificada em síncrona ou assíncrona,

dependendo do momento no qual os membros receberam as mensagens
enviadas pelo canal de comunicação. Diferentes canais de comunicação podem
ser utilizados para tornar a comunicação mais eficiente e produtiva, como, por
exemplo, chat ou audioconferência. Outra maneira de classificar a comunicação
diz respeito à existência de ligações entre os participantes, através tanto de
canais de comunicação direta, como troca de mensagens e reuniões, quanto por
meio de um canal indireto através da memória de grupo, onde a construção e o
compartilhamento do conhecimento comum podem ser considerados interfaces
de comunicação.
A coordenação do grupo que trabalha com uma ferramenta colaborativa

síncrona pode exigir um sofisticado mecanismo de controle das ações para
garantir o sucesso da colaboração. Mecanismos de controle de concorrência,
como travas ou transformação operacional, são utilizados para garantir a
consistência dos elementos que estão sendo manipulados pelos participantes da
colaboração no documento compartilhado. Em situações onde a probabilidade
de conflitos entre os usuários for baixa ou existir um moderador para coordenar
as ações dos usuários, o controle de concorrência pode ser dispensado. Nestas
54
situações, a coordenação das ações pode ficar a cargo do chamado protocolo

social, caracterizado pela ausência de mecanismos de controle explícitos entre
as atividades e pela confiança nas habilidades dos participantes de mediar por si
só as interações por meio de um canal de comunicação. Durante o trabalho em
grupo a percepção representa grande importância e apresenta relacionamento
com coordenação, comunicação e cooperação.
Nas ferramentas colaborativas síncronas a percepção permite que um

participante fisicamente separado esteja ciente da presença e das ações dos
demais participantes da colaboração, facilitando o aprendizado em conjunto.
A percepção também permite socializar virtualmente o ambiente e pode servir
para indicar o esforço dos participantes em interagir com a ferramenta e com os
demais participantes. A percepção, em geral, é implementada nas ferramentas
colaborativas síncronas por meio de elementos de percepção que fornecem
informações imediatas a respeito do estado dos participantes na colaboração e de
suas interações com a ferramenta.
Os elementos de percepção, apesar de vantajosos, não conseguem se

aproximar da riqueza de informações proporcionadas pela interação face a face
(SANTORO et al., 2002). A colaboração necessita que os participantes compartilhem
informações a este aspecto, é essencial para os grupos devido à necessidade de
prevenir esforços repetitivos e assegurar que todos os participantes do grupo
estejam utilizando a mesma informação, de forma que não haja inconsistências. As
ferramentas colaborativas geralmente fazem uso de documentos compartilhados,
como mecanismo de compartilhamento de informações e de armazenamento
da memória do grupo, que deve registrar todo o processo de interação, como
a própria comunicação realizada e passos desencadeados, bem como todos os
produtos gerados durante a colaboração.
A utilização de papéis predefinidos em ferramentas colaborativas tem

como objetivo principal estruturar as interações entre os participantes do grupo,
definir tarefas e gerenciar o acesso aos elementos do documento compartilhado.
Um papel descreve como um conjunto de indivíduos se relaciona com algum
elemento compartilhado e com os outros participantes restantes do grupo por
meio da especificação dos direitos e responsabilidades sobre diferentes tarefas
dentro do processo de aprendizagem. A definição de papéis também é utilizada
como um mecanismo de coordenação das atividades dos participantes, e
ainda como um mecanismo de controle de acesso a elementos do documento
compartilhado. No entanto, sua atribuição precipitada pode restringir o potencial
criativo dos participantes, ou seja, cada indivíduo somente efetuaria as operações
específicas de seu papel, sem que todo o seu potencial tenha sido alcançado. Além
dos aspectos funcionais, o uso de uma ferramenta colaborativa como instrumento
pedagógico deve levar em consideração a metodologia de ensino que está sendo
aplicada.
Várias metodologias de ensino já estão adaptadas para o uso de

ferramentas colaborativas, e nestas metodologias o principal foco é na realização
55
de tarefas por um grupo de alunos. Dentre essas metodologias, destacam-se:

resolução de problemas, estudo de casos e abordagem dos sete passos (PADILHA
et al., 2003). Os editores colaborativos CUTE (Collaborative UML Technique Editor)
(DIAS e XEXÉO, 1997) e CO2DE (Collaborate to Design) (BORGES et al., 2003) são
exemplos de iniciativas que permitem de edição colaborativa de diagramas da
UML, assim como as ferramentas CASE (Computer Aided Software Engineering),
comerciais Poseidon for UML (GENTLEWARE, 2006) e Magic Draw [No Magic
2006]. O principal objetivo destas ferramentas é o produto final obtido pelas
interações dos usuários, ao invés do processo de geração das interações.
Devido a este objetivo, poucos recursos didáticos e pedagógicos foram

implementados, tornando o suporte ao processo ensino-aprendizado limitado
nestas ferramentas. Várias análises são sugeridas para avaliar a eficácia e o
desempenho do aprendizado de alunos em atividades colaborativas. Lund e
Baker (1999) analisam as interpretações de professores das interações dos alunos
durante a resolução colaborativa de problemas. Padilha et al. (2003) propõem
técnicas de Data Mining que detectam regras de associação por meio dos valores
de variáveis observadas durante a colaboração. Avouris et al. (2003) descrevem
um toolkit genérico para análise e processamento de dados coletados durante
atividades de aprendizado colaborativas. Martinez et al. (2003) combinam
avaliação qualitativa e análise da rede social para analisar as interações sociais e
aspectos de participação no aprendizado colaborativo. Apesar de considerar os
dados coletados a partir de experimentos colaborativos, nenhuma das análises
citadas faz uso de índices quantitativos para auxiliar a avaliação da eficácia e
produtividade do aprendizado colaborativo.
3 EXPERIMENTO REALIZADO
3.1 CONTEXTO DO EXPERIMENTO
O intuito do estudo descrito neste artigo é apresentar ao professor uma

análise da eficácia do aprendizado dos grupos de alunos que utilizaram uma
ferramenta colaborativa para auxiliar a resolução de problemas. Um experimento
controlado foi conduzido para analisar a eficácia do aprendizado de grupos
de alunos que utilizaram uma ferramenta colaborativa no aprendizado da
modelagem de diagramas da UML. A ferramenta colaborativa escolhida para
realizar o experimento descrito neste artigo foi o ArgoUML (2006), que foi
adaptada para suportar a edição colaborativa. As adaptações incluem um chat, um
editor de diagramas da UML colaborativo e travas como mecanismo de controle
de concorrência, além de elementos de percepção remota, como, por exemplo,
telepointers e lista de elementos travados. A metodologia de ensino adotada
durante o aprendizado dos grupos no experimento foi a resolução de problemas.
Esta metodologia pode constituir tanto um conteúdo educativo como

um modo de conceber as atividades educativas. O ensino baseado na resolução
de problemas supõe fomentar nos alunos o domínio de procedimentos para dar
respostas a situações distintas e mutáveis (POZO, 1998).
56
3.2 AMBIENTE DO EXPERIMENTO
O experimento foi conduzido com o objetivo principal de coletar dados

para a análise da eficácia do aprendizado dos grupos de alunos. Este experimento
constou da observação tanto das interações e o comportamento dos grupos de
alunos, como também do modo no qual a ferramenta forneceu suporte para o
processo de elaboração de diagramas desde a ideia conceitual até a versão do
diagrama final. Para a realização do experimento, 12 alunos foram divididos, de
forma aleatória, em seis pares, sem repetições. Os alunos eram estudantes do
curso de pós-graduação com idades entre 23 e 34 anos (média de idade por volta
de 26 anos com desvio padrão igual a 2,27, incluindo seis homens e seis mulheres).
O experimento foi realizado entre novembro de 2005 e janeiro de 2006.
Os alunos participantes foram divididos em dois conjuntos: no primeiro

conjunto, os grupos 1, 2 e 3 utilizaram um chat como canal de comunicação, e no
segundo conjunto, os grupos 4, 5 e 6 utilizaram um software de audioconferência
para se comunicar. A divisão dos pares de alunos em dois conjuntos tem como
objetivo identificar a influência de diferentes canais de comunicação na evolução
do aprendizado. O ambiente utilizado no experimento foi composto de duas
salas, onde os alunos utilizaram o ArgoUML em suas estações de trabalho, sem
nenhum contato visual com seus parceiros. Em cada sala um experimentador
observou o comportamento do aluno, enquanto uma câmera de vídeo fez a
gravação das expressões faciais e do diálogo entre os alunos.
Cada aluno preencheu um formulário sobre seu perfil antes de iniciar as

tarefas que foram monitoradas no experimento. Em seguida, os alunos receberam
um documento explicando o cenário fictício e o problema em questão para cada
uma das três tarefas a serem completadas no experimento. Os alunos indicaram
aos experimentadores quando chegaram a um consenso sobre o término de cada
tarefa, para só então responderem a um questionário sobre o esforço requerido
pela tarefa completada. Ao término das três tarefas, cada aluno recebeu um
questionário de avaliação final e participou de uma breve entrevista com o
experimentador. Os principais dados objetivos coletados durante o experimento
foram registrados no log interno da ferramenta, que armazenou o histórico da
interação dos alunos entre si e com o editor colaborativo.
A gravação em vídeo das expressões faciais e do diálogo entre os alunos,

as respostas dos questionários e as observações do experimentador forneceram
informações subjetivas sobre o aprendizado.
3.3 VARIÁVEIS OBSERVADAS
A definição das variáveis a serem observadas durante a execução das

tarefas teve como base os recursos disponíveis no ambiente colaborativo para
a resolução de problemas e nos aspectos que evidenciam a aprendizagem. Na
Tabela 1 são apresentadas as variáveis observadas, bem como uma breve descrição
do seu significado e seus valores discretos. O valor numérico colocado entre
57
parênteses após o valor discreto da variável foi utilizado para o cálculo do índice
de aproveitamento, descrito na próxima seção. Os valores contínuos das variáveis
QtdElementos, QtdTravas, TempoGasto e QtdMensagens foram obtidos a partir
dos dados armazenados no log da ferramenta.
A transformação dos valores contínuos destas variáveis em valores discretos

se baseia na observação e análise dos valores contínuos e no contexto no qual os
pares executaram cada tarefa. Por exemplo, o valor discreto Alta para a variável
QtdMensagens, atribuída a uma tarefa executada por um par, leva em consideração o
valor contínuo da variável, o canal de comunicação utilizado e a comparação com os
valores contínuos dos demais pares para esta mesma tarefa e variável. Para os valores
das variáveis EsforçoPercebido e DificuldadeApontada nenhuma transformação
foi necessária, pois eles foram coletados diretamente dos questionários de esforço
requerido que continham perguntas cujas respostas apresentavam escalas de valores
correspondentes aos da Tabela 1 para estas variáveis.
Nome da variável Descrição da variável Valores discretos

Quantidade de elementos
QtdsElementos Alta(3), Média(2), Baixa(1)
criados
Quantidade de travas
QtdTravas concedidas nos elementos do Alta(3), Média(2), Baixa (1)
modelo
Tempo de duração total da
TempoGasto Longo(3), Médio (2), Curto(1)
tarefa
Muito esforço(5), Algum
Grau de esforço percebido
esforço(4), Esforço razoável(3),
EsforçoPercebido pelo par durante a realização
Pouco esforço (2), Nenhum
tarefa
esforço(1)
Grau de dificuldade apontado Muito difícil(5), Difícil(4),
DificuldadeApontada pelo par durante a realização Nem difícil nem fácil(3),
da tarefa Fácil(2), Muito fácil(1)
Quantidade de mensagens
QtdMensagens relevantes enviadas durante a Alta(3), Média(2), Baixa(1)
comunicação
4 ALTERNATIVA DE AVALIAÇÃO DA EVOLUÇÃO DA EFICÁCIA
A análise da evolução da eficácia de aprendizado dos alunos, para a

resolução dos problemas, é realizada considerando o conjunto de problemas,
assim é possível ter um mapeamento superficial do desempenho dos alunos. Com
os dados obtidos das variáveis, o professor pode medir a eficácia de aprendizado
dos alunos baseado no aspecto que melhor lhe convir. Neste artigo sugerimos
a utilização de um índice de aproveitamento que leva em consideração todas
as variáveis observadas durante o experimento, com o objetivo de auxiliar na
avaliação do desempenho do aprendizado dos grupos na resolução dos problemas
de forma colaborativa. O cálculo do índice de aproveitamento dos pares na
execução das tarefas foi baseado nas variáveis descritas na seção anterior.
58
O valor entre parênteses apresentado após o valor discreto das variáveis

na Tabela 1 é somado para cada tarefa de cada par. Deste modo, o índice considera
que o par teve um bom aproveitamento se todas as variáveis apresentarem
valores altos, tais como uma grande quantidade de elementos criados ou um
maior tempo gasto durante a tarefa. O índice de aproveitamento é calculado em
percentual com base no aproveitamento máximo possível obtido através da soma
dos valores de todas as variáveis observadas. Um gráfico de colunas com o índice
de aproveitamento calculado para cada par e tarefa é apresentado na Figura 1.
Este gráfico apresenta, em colunas, o aproveitamento dos pares em cada uma das
tarefas, considerando o índice de aproveitamento, em porcentagem. Analisando
os dados do gráfico pode-se inferir que os alunos do par 5 foram os únicos alunos
cujo aproveitamento foi constante nas tarefas 1 e 2, fato que pode ser explicado
pelos valores discretos iguais para as variáveis QtdTravas e TempoGasto nas duas
primeiras tarefas realizadas por estes pares. Já os pares 1, 4 e 6 mostraram um
maior aproveitamento na tarefa 2, pois eles possuíram o valor discreto Alta para
a variável QtdMensagens, valor este que provavelmente influenciou de forma
direta os valores das outras variáveis. Os pares 2 e 3 possuem uma queda de
aproveitamento em comum nas tarefas 2 e 3, que pode ser explicado pelo pouco
tempo gasto na execução destas tarefas em conjunto e também devido ao pouco
esforço gasto na execução destas tarefas.
100
90
87
80 74 74
Aproveitamento (%)
78
70 69
61 62 61 62 61 62
60 56
52 52
50 43 43 Tarefa 1
40 Tarefa 2
39 30 Tarefa 3
30
20
10
0
Par 1 Par 2 Par 3 Par 4 Par 5 Par 6
Pares
O índice de aproveitamento sugerido é uma proposta que auxilia a

avaliação do aprendizado dos alunos e deve ser utilizado em conjunto com
outros métodos de avaliação qualitativa, como, por exemplo, a nota que o
professor atribui às soluções dos problemas apresentados. Este índice é relevante
para pesquisados e educadores que estão envolvidos na análise e avaliação das
atividades de aprendizado e na modelagem e criação de novas ferramentas e
métodos para o estudo da eficácia de aprendizado em atividades colaborativas.
Ele tem como objetivo fornecer uma ideia superficial da eficácia e produtividade
do aprendizado dos grupos de alunos e ajudar o professor a detectar mais
facilmente o aproveitamento no aprendizado.
59
5 CONSIDERAÇÕES FINAIS
Este trabalho apresentou dados coletados a partir do uso de uma

ferramenta de modelagem colaborativa e propôs uma alternativa de avaliação do
aprendizado de grupos de alunos que utilizaram uma ferramenta colaborativa
para auxiliar o aprendizado da UML em um experimento controlado.
A utilização de ferramentas de groupware na instrução abre novas

possibilidades de aprendizado. Entretanto, a medição e a avaliação do desempenho
do aprendizado auxiliado por ferramentas colaborativas ainda carecem de estudos
mais aprofundados. Por meio da análise das interações dos alunos entre si e com a
ferramenta foi possível identificar os problemas que apresentaram maior ou menor
grau de dificuldade aos grupos, e também identificar os aspectos que podem influenciar
no aprendizado colaborativo. Com a possibilidade de coleta dos dados e do índice
de desempenho apresentados neste artigo, espera-se auxiliar o professor na avaliação
do desempenho do aprendizado dos grupos de alunos, além de fornecer recursos
para que o professor possa acompanhar e conhecer as dificuldades no aprendizado
dos alunos quando estes utilizam uma ferramenta colaborativa. Desta maneira, a
atividade de avaliação geral do professor pode ser amenizada, principalmente no
aspecto do acompanhamento do aprendizado do aluno. O ArgoUML adaptado para
permitir a edição colaborativa síncrona está disponível para download no endereço:
<http://www.comp.ita.br/~pichilia/argo.htm>.
Agradecimentos. Os autores gostariam de agradecer aos revisores

anônimos que contribuíram para a melhoria deste trabalho e a todos os envolvidos
na elaboração do experimento.
FONTE: Disponível em: <http://www.comp.ita.br/pichilia/argo.htm>. Acesso em: 10 out. 2015.
60
RESUMO DO TÓPICO 3
Neste tópico você viu que:
• Um diagrama de atividade mostra um processo de negócios ou um software

como um fluxo de trabalho por meio de uma série de ações. Computadores,
componentes de software ou as pessoas podem executar essas ações.
• Você pode usar um diagrama de atividades para descrever processos de

diversos tipos, como os exemplos a seguir:
o Um processo de negócios ou um fluxo de trabalho entre usuários e seu

sistema. Para obter mais informações, consulte Requisitos de usuário do
modelo.
o As etapas executadas em um caso de uso. Para obter mais informações,
consulte Diagramas de caso de uso UML: diretrizes.
o Um protocolo de software, ou seja, as sequências permitidas de interações
entre os componentes.
o Um algoritmo de software.

• O diagrama de máquina de estados mostra os estados que podem ser assumidos
por um objeto em seu ciclo de vida. Geralmente o utilizamos para entender
como tais mudanças acontecem, de modo a podermos definir as trocas de
mensagens e os métodos que as controlam.
61
AUTOATIVIDADE
1 Analise o Diagrama de Casos de Uso abaixo, referente a um módulo

de matrícula, e construa um Diagrama de Atividades para demonstrar
modelagem dos processos do negócio.
Consultar <<extend>> Consultar

Informações Informações
de Cursos de Turmas
Aluno
<<extend>>
<<include>> Realizar
Manter Aluno
Matrícula
2 Construa um Diagrama de Atividades para o seguinte processo de negócio:
- A autorização do pagamento tem início após um pedido ter sido realizado

pelo cliente.
- Ao mesmo tempo, a disponibilidade para cada um dos itens do pedido é
verificada pelo depósito.
- Se a quantidade requisitada de um determinado item existe em estoque,
tal quantidade é associada ao pedido, caso contrário, a quantidade do
item será alterada (se houver em quantidade menor), se a quantidade em
estoque for igual a zero, o item será excluído.
- O pedido é enviado pelo depósito ao cliente quando todos os itens
estiverem associados e o pagamento estiver autorizado.
- O pedido será cancelado se a ordem de pagamento não tiver sido autorizada.
3 Desenhe o diagrama de estados de uma tostadeira. Defina os diferentes estados

do pão na tostadeira, sem esquecer de especificar os necessários eventos, ações
e condições com guarda.
4 Uma das formas de modelar o aspecto dinâmico de um sistema com a UML

2.0 é através da utilização do diagrama de máquina de estado (state machine
diagram). Nesse contexto, considere os dois diagramas de máquinas de
estados representados a seguir, de acordo com a notação da UML. Considere
que os eventos e as atividades homônimas em ambos os diagramas têm o
mesmo significado.
62
A evento02/atividade02
entry/atividade00
evento01/atividade01
evento02/atividade02 A
entry/atividade00
evento01/atividade01
evento03
B evento03
Os dois diagramas de máquinas de estados apresentados são equivalentes

entre si.
PORQUE
Modelar o evento02 com uma transição recursiva (conforme o diagrama

da direita) é equivalente a modelar o evento02 com uma atividade interna
(conforme o diagrama da esquerda).
Analisando-se as afirmações acima, conclui-se que:
a) As duas afirmações são verdadeiras, e a segunda justifica a primeira.

b) As duas afirmações são verdadeiras, e a segunda não justifica a primeira.
c) A primeira afirmação é verdadeira, e a segunda é falsa.
e) As duas afirmações são falsas.
63
64
UNIDADE 2
DIAGRAMAS COMPORTAMENTAIS
(INTERAÇÃO)
Ao final desta unidade você será capaz de:
• conhecer as principais características dos diagramas compor-tamentais;
• elaborar diagramas comportamentais de interação;
• conhecer as principais características dos diagramas estruturais;
• elaborar diagramas estruturais.
PLANO DE ESTUDOS
Esta unidade de ensino contém três tópicos e no final de cada um deles você
TÓPICO 1 – DIAGRAMAS DE INTERAÇÃO
TÓPICO 2 – DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES
TÓPICO 3 – DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE COMPO-

NENTES
65
66
UNIDADE 2
TÓPICO 1
DIAGRAMAS DE INTERAÇÃO
1 INTRODUÇÃO
Diagramas de Interação representam como o sistema age internamente para
que um ator atinja seu objetivo na realização de um caso de uso, com o objetivo de obter
informações adicionais para completar e aprimorar outros modelos (principalmente
o modelo de classes), além de fornecer aos programadores uma visão detalhada dos
objetos e mensagens envolvidos na realização dos casos de uso.
A mensagem é o componente principal da interação entre objetos. Um

sistema orientado a objetos é uma rede de objetos que trocam mensagens. Objetos
só podem interagir através de mensagens. Por exemplo: um objeto envia uma
mensagem para outro objeto quando o primeiro deseja que o segundo realize
alguma tarefa. Neste sentido, os Diagramas de Interação mostram como os
objetos interagem uns com os outros, sendo usados tanto na análise quanto no
desenvolvimento do projeto de forma geral.
Estes diagramas modelam aspectos dinâmicos do sistema, ou seja, as

situações que sofrem mudanças ao longo do tempo.
Os Diagramas de Interação são: Diagrama de Sequência, Diagrama de

Comunicação, Diagrama de Tempo e Diagrama de Visão Geral.
2 DIAGRAMA DE SEQUÊNCIA
Detalham a sequência de um processo, representando os atores e objetos
envolvidos num cenário e a sequência de troca de mensagens ao longo do tempo
para realizar o cenário. É construído a partir do diagrama de casos de uso. Ordena
de forma temporal as mensagens trocadas entre os objetos.
A notação para uma mensagem em um Diagrama de Sequência é uma

flecha (geralmente desenhada na horizontal) ligando uma linha de vida à outra.
O objeto do qual parte a seta é aquele que está enviando a mensagem (objeto
remetente). O objeto para o qual a seta aponta é aquele que está recebendo a
mensagem (objeto receptor). O formato da ponta da seta indica o tipo de
mensagem sendo enviada (síncrona ou assíncrona). O rótulo da mensagem é
posicionado acima dessa seta.
67
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
Um Diagrama de Sequência permite identificar os métodos e atributos de

cada classe, assim como as responsabilidades de cada classe na realização de um
caso de uso. Os elementos básicos de um Diagrama se Sequência são (TACLA,
2010, p. 36):
• Atores: São entidades externas que interagem com o sistema e que

solicitam serviços. Normalmente, o ator primário é o responsável por
enviar a mensagem inicial que inicia a interação entre os objetos.
• Objetos: Representam as instâncias das classes representadas no
processo.
• Linha do tempo (uma para cada objeto e ator): As linhas de vida
compõem a dimensão vertical. Uma linha de vida é composta de duas
partes, a cabeça e a cauda. A cabeça é representada por um retângulo
com dois compartimentos, no compartimento superior a identificação
do objeto é exibida e no compartimento inferior (cuja utilização é
opcional) aparecem valores para os atributos definidos na classe do
objeto. A cauda corresponde a uma linha vertical tracejada.
• Comunicação: entre ator e objeto ou entre objetos.
• Interpretação das mensagens: por exemplo, evento do sistema operacional
ou de uma interface, envio de mensagem ou chamada de método.
FIGURA 33 – REPRESENTAÇÃO DE DIAGRAMA DE SEQUÊNCIA
objeto
:A :B
usuário
sincrona
ativação|
resposta
assincrona
Linha da
vida
FONTE: Piva (2010)
2.1 TIPOS DE MENSAGEM

Há vários tipos de mensagem que podem ser utilizados num Diagrama
de Sequência, sendo os mais comuns os seguintes:
68
TÓPICO 1 | DIAGRAMAS DE INTERAÇÃO
• Simples: quando o tipo de mensagem é irrelevante ou ainda não foi definido.

• Síncrona: quando enviada, o emissor fica bloqueado aguardando a resposta.
• Assíncrona: o emissor não bloqueia até que o receptor envie resposta para
continuar seu processamento.
• Retorno ou resposta: resposta à mensagem síncrona; pode ser omitida.
Uma mensagem é definida sintaticamente por:
• Expressão-sequência recorrência: v := mensagem

• Expressão-sequência: é um número sequencial de envio das mensagens.
Por exemplo, 1: msg1 2: msg2 representando que a mensagem msg1 precede
a msg2.
• Recorrência: indica um envio condicional ou uma repetição. Zero ou mais
mensagens são enviadas dependendo da condição envolvida. As opções
são:
*[cláusula-iteração] ou[guarda]
Não há sintaxe rígida definida pela UML, a cláusula de interação e

a condição de guarda podem ser especificadas em pseudocódigo ou na
linguagem-alvo.

Utiliza-se um Diagrama de Sequência quando há a necessidade de

representar o comportamento de vários objetos dentro de um contexto específico,
a partir de mensagens que são trocadas entre eles. Os atores são os mesmos do
diagrama de casos de uso. Um Diagrama de Sequência não representa atributos.
Passos para a criação de um Diagrama de Sequência:
• Escolher um caso de uso

• Identificar os objetos que fazem parte da interação
• Identificar o objeto que começa a interação
• Identificar as mensagens trocadas entre os objetos
• Identificar a sequência destas mensagens
Notação do Diagrama de Sequência
69
FIGURA 34 – NOTAÇÃO DO DIAGRAMA DE SEQUÊNCIA
Objeto Mensagens
Ator Tempo
FONTE: Disponível em: <http://www.dmo.fee.unicamp.br/henrique/
cursoc++/diagrama.pdf>. Acesso em: 10 out. 2015.
Exemplo de Diagrama de Sequência
FIGURA 35 – EXEMPLO DE DIAGRAMA DE SEQUÊNCIA
Sistema da
VideoLocadora
Cliente Atendente Gerente
Comunicar extravio de fita

Solicitar registro de aluguel
Buscar aluguel
Retornar registro de aluguel
Solicitar conversa com gerente.
Falar com Gerente

Solicitar registro da fita
Buscar fita
Retornar registro da fita
Negociar Multa
Pagar Multa
FONTE: Disponível em: <http://www.dmo.fee.unicamp.br/henrique/cursoc++/diagrama.pdf>.

Acesso em: 10 out. 2015.
2.2 DIAGRAMA DE COMUNICAÇÃO

Antes da versão 2.0 era chamado de Diagrama de Colaboração. Contempla
as mesmas informações que o Diagrama de Sequência, mas não considera a
dimensão temporal.
Considerando a sua estrutura, é semelhante a um Diagrama de Objetos,

sendo que a principal diferença entre os dois é que são adicionados setas e rótulos
70
de mensagens nas ligações entre esses objetos. E as ligações (linhas que ligam
objetos) remetem aos relacionamentos existentes entre os mesmos.
2.2.1 Principais componentes: objetos, mensagens e

vínculo
Para Tacla (2010, p. 34) “o Diagrama de Comunicação mostra a relação
entre os objetos, analisando a troca de mensagens entre eles. Mas não se preocupa
necessariamente com a ordem em que elas ocorrem, e sim com quais objetos as
mensagens são trocadas e quais são as mensagens”.
Diferente de um Diagrama de Sequência, um Diagrama de Comunicação

mostra os relacionamentos entre os objetos. Os Diagramas de Sequência e
os Diagramas de Comunicação expressam informações semelhantes, mas as
mostram de maneiras diferentes. Os Diagramas de Comunicação mostram os
relacionamentos entre os objetos e proporcionam uma melhor compreensão de
todos os efeitos causados em determinado objeto e para design de procedimentos.
Observe a Figura 36. Verifique que a composição é basicamente a mesma de

um Diagrama de Sequência, porém, em ordem diferente, com foco para as mensagens
trocadas entre os objetos, não em quando estas mensagens foram trocadas.
Pode-se então escolher em usar o Diagrama de Sequência ou o Diagrama

de Comunicação, podendo obviamente optar por criar os dois quando se tem
uma situação atípica para analisar.
71
FIGURA 36 – COMPONENTES DO DIAGRAMA DE COMUNICAÇÃO
:Funcionario
1: verificaFuncionario(cpf,senha): boolean
3: valorUnitario=verificaProduto(produto,quantidade): double
:Cliente :FRegistraProduto Produto
2: verificaCartao(nroCartao): boolean 4: ItemCompra(produto,quantidade,precoUnitarioVenda,

funcionario: boolean
:ItemCompra
5: atualizaTotalCompra(valorTotalItem: boolean
:Compra
FONTE: Piva (2010)
• Também chamado de Diagrama de Colaboração.

• Define a estrutura de como os objetos estão vinculados.
• Semelhante ao Diagrama de Classes.
• Indica quais mensagens são trocadas entre objetos.
• Semelhante ao Diagrama de Sequência S.
• Diagrama de Sequência se concentra na ordem temporal em que as mensagens
são trocadas.
• Diagrama de Comunicação se preocupa com a organização estrutural dos
objetos.
2.2.2 Notação: semelhante ao Diagrama de Sequência
Um dos principais objetivos do Diagrama de Comunicação é identificar

os vínculos que são ligações existentes entre os objetos envolvidos no processo.
Um vínculo é representado por uma linha unindo dois objetos.

Deve existir relacionamento equivalente no Diagrama de Classes.
72
FIGURA 37 – NOTAÇÃO
curso1: Curso turma1:Turma
FONTE: O autor
As notações são as mesmas definidas no Diagrama de Sequência e

geralmente representam chamadas de métodos.
No Diagrama de Comunicação não existe a preocupação com a ordem,

somente com quem dispara a mensagem, não existindo mensagens de retorno.
FIGURA 38 – REPRESENTAÇÃO DE MENSAGENS

1: VisTurma( )
curso1: Curso turma1:Turma
FONTE: O autor
2.2.3 Atores
São os mesmos do Diagrama de Sequência e Casos de Uso. Atores enviam
e recebem mensagens através de vínculos, assim como ocorre com os objetos no
Diagrama de Comunicação.
2.2.4 Condições
São condições que devem ser atendidas para que uma mensagem possa
ser enviada. Notação: a condição vem entre colchetes antes da mensagem.
FIGURA 39 – REPRESENTAÇÃO DE CONDIÇÕES
Gerente [se saldo = 0] encerrarConta( )
minha_conta: Conta
FONTE: O autor
73
2.2.5 Autochamadas
Objetos podem disparar mensagens para eles mesmos, como ocorre
no Diagrama de Sequência. Esta situação indica que o objeto tem que fazer
determinada tarefa para finalizar o serviço solicitado.
FIGURA 40 – REPRESENTAÇÃO DE AUTOCHAMADAS
fisica1:Fisica
1: valCPF0
FONTE: O autor
2.2.6 Exemplo de Diagrama de Comunicação

FIGURA 41 – DIAGRAMA DE COMUNICAÇÃO
1: conCPF0
:Banco 2: [Se necessário] Gravar ( )
3: Abertura ( ) fisica1:Fisica
4: Gravar ( )
conta1: Conta Comum hist1: Histórico
FONTE: O autor
Passos para criar um Diagrama de Comunicação
• Verificar a consistência dos diagramas de interação em relação aos Casos de

Uso e ao modelo de classes.
• Cada cenário relevante para cada caso de uso deve ser considerado na
modelagem de interações.
• Durante a construção do Diagrama de Interação pode-se identificar novas
classes.
• Atributos, associações e operações também surgem como subproduto da
construção dos Diagramas de Interação.
74
2.3 DIAGRAMA DE TEMPO

O Diagrama de Temporização foi incluído a partir da UML 2.0 e apresenta
o comportamento dos objetos e sua interação em uma escala de tempo, sempre
com foco para as situações que mudam num determinado intervalo, além
de descrever a interação e a evolução de estados, e de monitorar as restrições
temporais do sistema (MELO, 2011).
Colaborando, Guedes (2011, p. 76) complementa: “O Diagrama de

Temporização ou de tempo apresenta a mudança no estado ou condição de uma
instância de uma classe ou seu papel durante um período. Utilizado para mostrar
a mudança no estado de um objeto no tempo em resposta a eventos externos”.
É um diagrama de interação, pois mostra os tempos reais em diferentes

objetos e papéis, em vez de sequências de mensagens relativas. São geralmente
utilizados em projetos de sistemas de tempo real, onde impera o tempo gasto na
troca de mensagens e de estado na execução de todas as tarefas. Por este motivo,
não são utilizados em todos os tipos de projetos, somente nos casos em que o
tempo seja um fator determinante (TACLA, 2010).
Descreve a mudança no estado ou na condição de uma instância de uma

classe ou seu papel durante um tempo. É tipicamente utilizado para demonstrar
a mudança no estado de um objeto no tempo em resposta a eventos externos.
Os principais componentes do diagrama de tempo são: classes, linha de

tempo, mensagens. A figura a seguir mostra um exemplo de diagrama de tempo.
FIGURA 42 – DIAGRAMA DE TEMPO

td Sistema de Controle de Submissões - Estados do Congresso
{03/01..31/03} {01/04..31/05} {01/06..15/06} {11/07..15/07}

Aceitando submissões
:Congresso
Avaliando submissões
Comunicando autores
Realizando congresso
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100
FONTE: Disponível em: <https://www.novatec.com.br/livros/uml2-2ed/capitulo9788575223857.

pdf>. Acesso em: 15 out. 2015.
75
2.4 DIAGRAMA DE VISÃO GERAL

Através do Diagrama de Visão Geral é possível aglomerar vários tipos
distintos de diagramas. Podemos entendê-lo como uma variação dos diagramas de
atividade e sequência, uma vez que sua notação é a mesma destes dois diagramas.
São utilizados em situações complexas, para simplificar determinadas

situações. São eficazes em reuniões quando existe a necessidade de demonstrar
cenários de alta complexidade. Uma particularidade é que, conforme mencionado
acima, não possui uma notação específica.
Este diagrama permite capturar de uma perspectiva estática os fluxos
de interação entre os componentes do sistema, de forma geral, do
funcionamento global do sistema, de forma similar ao modelo expresso
pelo Diagrama de Atividades, que mostra o fluxo de um subsistema,
ou de uma dada funcionalidade em questão (TACLA, 2010, p. 45).
Ainda de acordo com o autor, o objetivo precípuo deste diagrama consiste

em analisar as sequências necessárias para executar determinada funcionalidade
do sistema que está sendo elaborado. Como exemplo de funcionalidade podem
ser citados vários casos de uso.
Os principais componentes do diagrama de visão geral são: diagramas de

sequência, decisões, fluxos.
76
RESUMO DO TÓPICO 1
• Os Diagramas de Interação constituem um passo importante nesta divisão, pois

detalham os objetos das classes de análise e, por consequência, quais operações
cada um deve realizar. Se um caso de uso possui vários fluxos, pode ser útil
criar um diagrama de interação para cada cenário. Os diagramas de interação
mais utilizados são o de Sequência e o de Comunicação (ex-colaboração).
• Diagramas de Interação são usados tanto na análise quanto no projeto. Na

análise, as comunicações entre objetos são mais abstratas, não importando
muito os argumentos e valores retornados. No projeto, o detalhamento é maior.
• Os diagramas de Interação são: Diagrama de Sequência, Diagrama de

Comunicação, Diagrama de Tempo e Diagrama de Visão Geral.
• Um Diagrama de Sequência representa os atores e objetos envolvidos num cenário

e a sequência de troca de mensagens ao longo do tempo para realizar o cenário.
• Um Diagrama de Sequência permite identificar os métodos e atributos de cada

classe, assim como as responsabilidades de cada classe na realização de um
caso de uso. Os elementos básicos de um Diagrama de Sequência são:
o Atores
o Objetos
o Linha do tempo (uma para cada objeto e ator)
o Comunicação entre ator e objeto ou entre objetos
o Interpretação das mensagens: por exemplo, evento do sistema operacional ou
de uma interface, envio de mensagem ou chamada de método.
• Diagrama de Comunicação (antes da versão 2.0 era chamado Colaboração) é

outra forma de representar um cenário: contém as mesmas informações que o
Diagrama de Sequência, mas não considera a dimensão temporal. Alguns autores
recomendam utilizá-lo para analisar a colaboração das classes de realização de
um caso de uso, pois facilita a identificação das classes que colaboram de forma
mais próxima e, por consequência, a identificação de pacotes de análise.
o Principais componentes: objetos, mensagens.
• O Diagrama de Comunicação mostra a relação entre os objetos, analisando a

troca de mensagens entre eles. Mas não se preocupa necessariamente com a
ordem em que elas ocorrem, e sim com quais objetos as mensagens são trocadas
e quais são as mensagens.
77
• Em muitos projetos, usa-se ou o Diagrama de Sequência ou o Diagrama de
Comunicação, mas também pode-se criar ambos para análise de alguma
situação particular.
• É um Diagrama de Interação, que mostra os tempos reais em diferentes objetos

e papéis, em vez de sequências de mensagens relativas (BOOCH; RUMBAUGH;
JACOBSON, 2005).
• O Diagrama de Temporização, como o nome diz, tem seu foco principal no estudo
do tempo gasto nas trocas de mensagens entre os componentes do sistema.
• Esse é um diagrama de uso específico, que não se utiliza em todos os projetos.

o Principais componentes: classes, linha de tempo, mensagens.
• O Diagrama de Visão Geral Congrega uma determinada visão que pode

englobar vários diagramas.
• Geralmente o Diagrama de Visão Geral de interação é uma variação do

Diagrama de Atividades mais o Diagrama de Sequência, proposto na versão
atual de UML. Seus elementos sintáticos são os mesmos dos Diagramas de
Atividades e Sequência.
• As interações que fazem parte do Diagrama de Visão Geral de interação podem

ser referências a diagramas de interação existentes na especificação tratada.
• É necessário, em casos em que as sequências das interações se mostrarem

tão complexas, que requisitem um resumo que possibilite uma visão geral
daquela situação.
• É muito eficaz em reuniões e demonstrações de situações complexas, devemos

utilizá-lo de forma intensiva, pois não existe outro diagrama que nos dê uma
visão tão completa dos passos que uma situação, classe ou objeto possa passar.
• Não possui notações próprias.
• Em geral usa as mesmas notações dos diagramas dos quais está englobando.
• Geralmente usa a mesma notação do Diagrama de Atividades.
o Principais componentes: diagramas de sequência, decisões, fluxos.
78
AUTOATIVIDADE
1 Construa um Diagrama de Sequência para abrir uma conta, conforme a

descrição abaixo:
O cliente que deseja abrir uma conta no banco encaminha um pedido

de abertura de conta, com a documentação necessária. O funcionário do banco,
então, irá consultar o cadastro do cliente por meio do seu CPF, para determinar
se o solicitante já se encontra cadastrado. Se o cliente já estiver cadastrado,
a consulta retornará as informações do cliente, caso contrário retornará um
valor significando que o cliente ainda não possui cadastro na instituição.
Em seguida, o cadastro do cliente poderá ser atualizado, caso necessário,
podendo gerar uma nova instância da classe Cliente, se o solicitante ainda não
estiver registrado, ou simplesmente atualizar os dados do mesmo, se houver
necessidade de alguma atualização. Antes de finalizar a atualização do cliente,
algumas inconsistências devem ser levadas a efeito, uma delas é o disparo do
método para validação do CPF pelo próprio objeto da classe Cliente. Após o
término da atualização, o objeto da classe cliente retornará algum sinal para o
funcionário do banco, para indicar que o cliente foi atualizado com sucesso ou
se ocorreu algum erro. O banco então irá informar ao cliente se o seu pedido
foi ou não aprovado. Em caso de aprovação, o cliente irá fornecer o valor
inicial necessário para a abertura da conta e escolherá a senha. O funcionário
irá disparar o método de abertura na classe ContaComum, ou seja, criará um
novo objeto ContaComum. Após ter sido criado pela chamada do método
abertura, o objeto de ContaComum irá disparar o método gravar para gerar
uma nova instância da classe Historico, registrando o movimento gerado
pela abertura da conta, pois, para abrir uma conta, a instituição exige que o
cliente deposite algum valor na mesma. O método gravar retornará um sinal
indicando que o movimento foi registrado com sucesso e o método abertura
disparado na classe ContaComum, por sua vez, retornará o número da conta
gerado, indicando que a conta foi criada com sucesso e finalizando o processo
de abertura de conta.
FONTE: Disponível em: <http://professoralucelia.com.br/projSistemas/ExerciciosDiagramaDe

Sequencia03.pdf>. Acesso em: nov. 2015.
2 Elabore um Diagrama de Comunicação para que um cliente possa abrir

uma conta.
 Utilize as classes PessoaFisica, ContaComum e Histórico, conforme modelo

abaixo.
 Como atores, considere Cliente e Banco.
79
PessoaFisica
+ ConsultaCP F( ) : Int
+ ValidaCPF ( ) : System .Boolean
+ Gravar ( ) : System .Boolean
ContaComum Historico
+ Abertura ( ) : Int + Gravar ( ): System . Booelan
3 São diagramas de interação da UML que mostram um conjunto de objetos

e as mensagens que poderão ser trocadas entre eles, enfatizando a ordem
temporal de mensagens:
a) Diagrama de Atividades.
b) Diagrama de Objetos.
c) Diagrama de Comunicação.
d) Diagrama de Sequências.
4 Analise as seguintes afirmativas sobre os Diagramas de Interação da UML.
I - Um Diagrama de Interação mostra a interação entre um conjunto de objetos

e seus relacionamentos, incluindo as mensagens que poderãos ser trocada
entre eles.
II - Diagramas de Sequência e Diagramas de Colaboração são Diagramas de
Interação e modelam aspectos dinâmicos de sistemas.
III - Diagramas de Colaboração dão ênfase à ordenação temporal das mensagens
trocadas entre os objetos.
Marque a alternativa CORRETA:
a) ( ) Apenas as afirmativas I e II são verdadeiras.

b) ( ) Apenas as afirmativas I e III são verdadeiras.
c) ( ) Apenas as afirmativas II e III são verdadeiras.
d) ( ) Todas as afirmativas são verdadeiras.
80
UNIDADE 2 TÓPICO 2
DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES
1 INTRODUÇÃO
Modelam as situações estáticas do sistema, ou seja, seu esqueleto e
estruturas estáveis, que não sofrem mudanças (OMG, 2006).
Para Andrade (2007, p. 68), “a função dos diagramas estruturais é mostrar

as características do sistema que não mudam ao longo do tempo. Os aspectos
estáticos de um sistema de software envolvem a existência e a colocação de itens
como classes, interfaces, colaborações, componentes”. A figura a seguir, ilustra os
diagramas estruturais da UML.
FIGURA 42 - DIAGRAMAS ESTRUTURAIS
Diagramas
Estruturais
Diagrama de
Diagrama Diagrama de Diagrama Diagrama
Estrutura
de Objetos Implementação de Classes de Pacotes
Composta
Componentes Implantação
FONTE: Piva (2010)
2 DIAGRAMA DE CLASSES
É apontado como sendo o diagrama mais utilizado, pois mostra o conjunto
de classes, interfaces, colaborações e relacionamentos. Sua utilização é ampla,
tendo início desde o momento da análise até o detalhamento da especificação
(GUEDES, 2011). É considerado também o diagrama que possui o maior
detalhamento quando pensamos em notações.
É este diagrama que se aproxima mais da realidade de um código de

programa, pois mostra conjunto de classes com seus atributos e métodos e os
relacionamentos entre classes, amplamente utilizado no desenvolvimento de
aplicações orientadas a objetos (LARMAN, 2007).
81
Apresenta as relações:
• associação (mais comum);

• agregação (um tipo de associação);
• generalização/especialização.
FIGURA 43 – CLASSE CLIENTE
Clientes
- codPessoa
- num Cliente
+ setCadastrar ( )
+ getConsultar ( )
FONTE: O autor
A importância deste diagrama consiste no fato de que cada classe do

diagrama representa uma tabela do banco de dados. Importante frisar que para
identificar uma classe é necessário que antes se identifiquem os objetos que
contenham características familiares ou semelhantes.
Quando se analisa uma situação real (cenário), é normal que se identifiquem

vários objetos. Porém, nem todos farão parte do Diagrama de Classes. Para
identificar os objetos essenciais deve-se colocar em prática o conceito de abstração,
cuja finalidade é manter o foco somente nos aspectos relevantes da situação.
Como exemplo para o desenvolvimento do Diagrama de Classe, usaremos

o cenário proposto por Tacla (2010, p. 65). Neste exemplo será possível identificar
todas as classes para fazermos as ligações e determinarmos a cardinalidade.
2.1 CENÁRIO
Você trabalha para uma empresa de desenvolvimento como analista de
sistemas. O responsável pelo setor onde você trabalha, em uma reunião, distribuiu
tarefas para cada membro da equipe. Sua tarefa foi desenvolver um diagrama de
classe para que seja iniciado o desenvolvimento de um novo software.
A empresa que nos contratou deseja adquirir o certificado ISO 9001 em

qualidade, entretanto, uma das normas repassadas foi que deve ser obrigatório
controlar os pedidos de suporte/serviço que são feitos pelos clientes.
O ramo da empresa é Service Desk[1] e o fluxo do processo segue abaixo:
82
TÓPICO 2 | DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES
Cliente entra em contato com a central através do telefone
Um atendente tem um prazo curto para registrar esta solicitação,

informando os dados do cliente, o que foi solicitado, o nível de urgência, o
grupo de atendimento, o técnico, um ou mais equipamentos envolvidos na
manutenção. Anotar toda a interação realizada no equipamento, como, por
exemplo: Se ele conectar remotamente ao equipamento, deve informar em um
histórico, e suponhamos que três segundos depois ele reinicie o equipamento,
deverá informar no histórico também. Resumindo: Toda interação deve ser
anotada no registro com data e hora.
Caso ele consiga resolver o que foi solicitado, o técnico do Service Desk
irá salvar o registro com a situação de “Resolvido” encerrando o caso, contudo,
deverá, em um local específico do registro, definir como ele resolveu o caso,
informando que se tratava de um Incidente[2], Problema[3] ou Solicitação[4]. O
registro deve ser categorizado, escolhendo dentre três classificações: Categoria
>>SubCategoria >> Item da categoria, onde a categoria é uma lista de tipo de
serviço, como, por exemplo: Se foi Hardware ou Software.
FONTE: Disponível em: <http://www.linhadecodigo.com.br/artigo/3219/orientacoes-basicas-na-

elaboracao-de-um-diagrama-de-classes.aspx>. Acesso em: nov. 2015.
A SubCategoria está relacionada com a categoria, pois dependendo

do que foi escolhido na primeira lista, será mostrada na segunda que será
uma SubCategoria, como, por exemplo: No caso da escolha de Hardware, seria
informado na subcategoria algum tipo de peça do equipamento que o técnico
interagiu, tipo DVD/R, no caso de Categoria ser Software a subcategoria deveria
ser qual software, tipo: Word, Excel e etc... E no item da categoria deveria ser
escolhido o que foi realizado pelo técnico, no caso de Hardware >> DVD/R,
poderia ser SUBSTITUÍDO, LIMPADO... etc. No caso de Software >> Word >>
INSTALADO, DESINSTALADO etc...
Caso o técnico do Service Desk não consiga resolver no seu prazo que
será o mais curto, deverá enviar o registro para outro grupo de atendimento,
onde existirão outros técnicos que poderão ir até o equipamento fisicamente
para resolver o problema com um prazo mais extenso. Um grupo é composto
por vários técnicos, no registro deve constar o grupo que atendeu e o técnico,
pois cada registro conta como receita em reais para o grupo sendo apurado ao
efetuar fechamento mensal. O pagamento para os grupos de atendimento é feito
por quantidade de registros atendidos no prazo estipulado.
83
Se o mesmo grupo de atendimento físico tenta entrar em contato com o

cliente, mas não obtiver sucesso, o técnico poderá deixar o registro agendado; para
realizar esta tarefa devem ser informadas no registro a data e a hora em que será
retornado o atendimento do chamado e definir a situação do registro para “Pendente
pelo cliente”, definir também a data e hora para o próximo contato. Esta situação de
pendência significa que o técnico não está atendendo por culpa do cliente e o tempo
em que o registro fica nesta situação será debitado ao final da apuração, a fim de
beneficiar o grupo que o atende, pois cada grupo tem um tempo para atender os
registros, e se ultrapassar este prazo, recebe multa em cima do valor do chamado.
Ao final, caso o pedido tenha sido designado para outro grupo, ou esteja
em andamento, pendente, cancelado ou resolvido, deve-se informar em um
campo específico o que foi feito neste registro, resumidamente. Se a situação do
registro estiver definida como “Resolvido”, uma pesquisa de satisfação deverá
ser enviada para o solicitante.
FONTE: Disponível em: <http://www.linhadecodigo.com.br/artigo/3219/orientacoes-basicas-na-

elaboracao-de-um-diagrama-de-classes.aspx>. Acesso em: nov. 2015.
2.2 IDENTIFICAR OS OBJETOS TANGÍVEIS

Para identificar somente os objetos que interessam na situação detalhada
acima, Tacla (2010) sugere que adotemos como regra o seguinte questionamento:
“O objeto é algo tangível, que podemos percebê-lo à nossa frente, sendo possível
encontrá-lo no mundo real ou virtual. Exemplos de objetos que podemos perceber
ao ir a uma lanchonete: Mesa, Cadeira, Atendente, Lanche, Bebida e etc.”.

Analise frase a frase do cenário proposto, obedecendo à regra descrita acima.
Logo, você identificará os seguintes objetos:
Cliente
Telefone
Atendente
Solicitação
Grupo
Técnico
Equipamento
Histórico
Categoria
SubCategoria
Item da categoria
Pedido
Pesquisa de satisfação
Situações
Tipo de serviços
Prazos
84
Histórico não é algo tangível, porém, é algo que existe. Neste caso,
podemos entender como o histórico de ocorrências envolvendo o cliente.
2.3 AGRUPAR OS OBJETOS POR SEMELHANÇA

Todos os objetos encontrados devem ser agrupados quando houver
semelhança. Exemplo:
Cliente, Atendente e Técnico = Pessoas

Solicitação, Histórico, Pedido e Pesquisa de Satisfação = Documentos
Telefone = Equipamentos
2.4 DELIMITAR CLASSES REDUNDANTES OU QUE NÃO SÃO

NECESSÁRIAS
Podemos observar que Pedido e Solicitação no cenário fazem referência a
uma mesma coisa, assim, podemos então eliminar uma das duas. E Telefone é um
item de equipamentos, podendo ser eliminado também.
Logo, a lista atualizada ficaria assim:

Pessoas
Cliente
Atendente
Grupo
Técnico
Equipamento
Histórico
Categoria
SubCategoria
Item da categoria
Pedido
Pesquisa de satisfação
Situações
Tipo de serviços
Prazos
2.5 MONTANDO O DIAGRAMA DE CLASSE

Veja, na figura a seguir, como deve ficar o esboço do Diagrama de Classe.
85
FIGURA 44 – REPRESENTAÇÃO DA MONTAGEM DO DIAGRAMA DE CLASSE
Pessoas
- codPessoa
- Pessoa
Clientes Atendentes Técnicos

Grupos
- codPessoa - codPessoa - codPessoa
- codGrupo
- numCliente - numAtendente - numTecnico
- codFuncionario
+ setCadastrar ( )
+ getConsultar ( )
Pedidos Categorias
- codOrdem - codCategoria
- codDoc - categoria
- codCliente
- codFuncionario
- codGrupo
- codTipo Sub_Categorias
- codCategoria
- codsubCategoria - codCategoria
- codItem - subCategoria
Tipos de Serviços Documentos Itens_da_

- codTipo - codDoc Categoria
- documento - coditem
- item
FONTE: O autor
2.6 REALIZANDO AS PRIMEIRAS LIGAÇÕES

Para efetuarmos a primeira ligação, faremos com os objetos que agrupamos
por características semelhantes, como, por exemplo: Clientes, Atendentes e
Técnicos se relacionam com pessoas; Pedido se relaciona com Documentos.
Verifique as ligações:
86
FIGURA 45 – LIGANDO AS CLASSES DE PESSOA
Pessoas
- codPessoa
- Pessoa
Clientes Atendentes Técnicos

- numCliente - numAtendente - numTecnico
+ setCadastrar ( )
+ getConsultar ( )
FONTE: Tacla (2010)
Parte do Diagrama de Classe envolvendo Pedidos e Documentos:
FIGURA 46 - LIGAÇÃO DE PEDIDOS E DOCUMENTOS
Pedidos
- codOrdem
- codDoc
- codCliente
- codFuncionario
- codGrupo
- codTipo
- codCategoria
- codsubCategoria
- codItem
Documentos
- codDoc
- documento
FONTE: Tacla (2010)
Para fazer as ligações, todas as classes devem ser testadas.
Sabemos que o cliente entra em contato com o atendente que gera um

pedido. Com esta informação observamos que um pedido foi gerado da
interação entre cliente e atendente, onde um cliente pode solicitar vários
pedidos para um atendente e um atendente atende a vários clientes.
Sua cardinalidade será N para N, onde N quer dizer muitos, sendo:
Muitos para Muitos, quando ocorre esse tipo de cardinalidade nasce
uma nova tabela ou classe, entre esses dois foi a classe pedidos, que já
87
havíamos identificado antes. O importante sobre a N para N é que a

classe que nasceu recebe os códigos da classe que o fez relação, ficando
a classe “Pedido” com o código do cliente e o código da atendente.
Sabemos também que esse pedido será repassado para um técnico que
o atenderá, sendo assim, um técnico pode atender a vários pedidos e um
pedido pode ser atendido por um técnico, sendo representado por 1-N,
lembrando que a classe que recebe o N herda o campo-chave da outra
classe como chave estrangeira, sendo assim ficará a tabela de pedidos
com mais um campo, chamado: código do técnico. Faça o processo para
todas as classes, use sempre a pergunta dessa forma:
Um “Nome de um objeto da classe” pode “nome da ligação (verbo)”
um ou vários “nome da classe”
Como ficaria entre Pedidos e situação: Um pedido pode ter uma ou
várias situações? Resposta: Várias, pois ao abrir está em andamento,
em outro ponto do tempo pode ficar pendente e ser concluída ao final
do serviço (TACLA, 2010, p. 76).
3 DIAGRAMA DE CLASSE COMPLETO

A figura a seguir mostra como ficaria o diagrama de classe completo, baseado
na situação descrita nos itens anteriores.
88
FIGURA 47 – DIAGRAMA DE CLASSE COMPLETO
Pessoas
- codPessoa
- Pessoa
Clientes Atendentes Tecnicos

- numCliente - numAtendente Grupos
- numTecnico
+ set1Cadastrat ( ) - codGrupo
+ getConsultar ( ) - codFuncionario
Equipamentos Pedidos
- codEquipamento - codOrdem Categorias
- codDoc
- codCliente - codCategoria
- codFuncionario - categoria
Pedido_Equipamentos - codGrupo
- codTipo
- codPedido - codCategoria Sub_Categorias
- codEquipamento - codsubCategoria
- codCategoria
- codItem
- subCategoria
Tipos de Serviços Itens_da_Categoria
- codTipo - codItem
Histórico_de_Atendimento - Item
- codHistorico
- codDoc
Pedido_Situações
- codSituação
- codOrdem Situações
- tempoNaSituação - codSituação
- situação
FONTE: Piva (2010)
3.1 DIAGRAMA DE PACOTES

O termo Diagrama de Pacotes é utilizado para descrever um diagrama
que mostra pacotes de classes e as dependências entre eles. Este diagrama
oferece uma visão do sistema como um todo, sob tal perspectiva que se possa
observar todos os subsistemas que o compõem. Tem como proposta apresentar
a modelagem estrutural do sistema em divisões lógicas e suas interações em alto
nível (SILVA, 2007).
89
• É uma construção de agrupamento que permite a você pegar qualquer

construção na UML e agrupar seus elementos em unidades de nível alto.
• Representa um grupo de classes (ou outros elementos) que se relaciona com
outros pacotes através de uma relação de dependência.
Os pacotes também podem ser membros de outros pacotes, construindo

uma estrutura hierárquica.
• Cada pacote representa um espaço de nomes, o que significa que toda classe
deve ter um nome exclusivo dentro do pacote a que pertence. Se eu quiser
criar uma classe Date e já existir uma classe Date dentro do pacote System,
eu posso ter minha classe Date, desde que a coloque em um outro pacote.
• É um mecanismo de agrupamento geral que serve para agrupar vários
modelos.
• Organiza elementos em grupo e costuma ser utilizado na modelagem de
sistemas muito extensos.
• São utilizados para demonstrar os limites de cada subsistema e como eles se
inter-relacionam.
• Pode conter qualquer diagrama da UML, inclusive outros pacotes. Mais
comumente utilizado em Diagrama de Casos de Uso e Diagrama de Classes.
FONTE: Disponível em: <http://200.17.137.109:8081/novobsi/Members/giordano/aulas/2010.2/

modelagem-e-programacao-orientada-a-objetos/Diagrama%20de%20Pacotes.pptx.>. Acesso em:
10 out. 2015.
FIGURA 47 – DIAGRAMA DE PACOTES
Sistema Seguradora Sistema Financeiro
FONTE: O autor
3.1.1 Definindo as classes de um Pacote

Para identificar as classes de um pacote, observe o seguinte:
• Classes que estejam na mesma árvore de herança.

• Classes que estejam em um mesmo jogo de agregação e composição.
• Classes que apareçam em um mesmo Diagrama de Sequência com muitas
colaborações (alto acoplamento).
• Um pacote utilitário contém classes sem afinidade direta com o domínio do
problema, porém necessárias.
90
FIGURA 48 – FORMAS DE REPRESENTAR DIAGRAMAS DE PACOTES
util util
util Date Date
Conteúdo listado Conteúdo diagramado

na caixa na caixa
java
util
java::util
Date
Date
java::util::Date
Nome de pacote Pacotes aninhados Nome de classe

totalmente qualificado totalmente qualificado
FONTE: O autor
É um diagrama estrutural que permite uma visão da organização interna

da aplicação que está sendo projetada.
3.1.2 Principais componentes: pacotes

Verifique outro exemplo de Diagrama de Pacotes na figura a seguir. Um
exemplo de pacote que organiza o projeto, pois separa as classes do projeto das
interfaces do usuário.
91
FIGURA 49 – COMPONENTES DO DIAGRAMA DE PACOTES
Classes de Projeto
Funcionario
GUI
Caixa
Floguin Dono Atendente
FManutençãoCompra
ItemCompra Compra
FManutençãoFornece Fornece
FManutençãoPagamentoCompra Cliente Produto ItemFornece

ItemCompra
FONTE: Piva (2010)
92
RESUMO DO TÓPICO 2
• O Diagrama de Classes é possivelmente o diagrama mais utilizado e um dos

mais importantes da UML. Serve de apoio para a maioria dos demais.
• É um diagrama que mostra um conjunto de classes, interfaces e colaborações

e seus relacionamentos. O Diagrama de Classes é utilizado na construção do
modelo de classes desde o nível de análise até o nível de especificação.
• Um diagrama de classes ilustra as especificações para as classes de software e de

interface de uma aplicação. Este diagrama mostra definições para entidades de
software, e não conceitos do mundo real (LARMAN, 2007). Produz a descrição
mais próxima da estrutura do código de um programa, ou seja, mostra o
conjunto de classes com seus atributos e métodos e os relacionamentos entre
classes. Classes e relacionamentos constituem os elementos básicos do diagrama
de classes (SILVA, 2007).
• O diagrama de classes é um dos principais diagramas da UML, representa a

estrutura do sistema (elementos que foram selecionados para fazer parte do
sistema). A partir dele, por exemplo, o esqueleto do código-fonte pode ser
gerado automaticamente.
• O comportamento requerido do sistema é alcançado pela colaboração entre

objetos. O Diagrama de Classes fornece uma representação estática da
colaboração por meio de relacionamentos. Os relacionamentos são utilizados
no Diagrama de Classes que é refinado incrementalmente (modelo do domínio,
análise e, posteriormente, no projeto).
• Em programação, um Diagrama de Classes é uma representação da estrutura

e relações das classes que servem de modelo para objetos. Podemos afirmar,
de maneira mais simples, que seria um conjunto de objetos com as mesmas
características, assim saberemos identificar objetos e agrupá-los, de forma
a encontrar suas respectivas classes. Na Unified Modeling Language (UML)
em Diagrama de Classe, uma classe é representada por um retângulo com três
divisões, são elas: O nome da classe, seus atributos e, por fim, os métodos.
• Diagrama de Pacotes é uma construção de agrupamento que permite a você

pegar qualquer construção na UML e agrupar seus elementos em unidades de
nível alto.
93
• Representa um grupo de classes (ou outros elementos) que se relaciona com
outros pacotes através de uma relação de dependência.
• Os pacotes também podem ser membros de outros pacotes, construindo uma

estrutura hierárquica.
o Cada pacote representa um espaço de nomes, o que significa que toda classe
deve ter um nome exclusivo dentro do pacote a que pertence. Se eu quiser
criar uma classe Date e já existir uma classe Date dentro do pacote System, eu
posso ter minha classe Date, desde que a coloque em um outro pacote.
o É um mecanismo de agrupamento geral que serve para agrupar vários
modelos.
o Organiza elementos em grupo e costuma ser utilizado na modelagem de
sistemas muito extensos.
o São utilizados para demonstrar os limites de cada subsistema e como eles se
inter-relacionam.
o Pode conter qualquer diagrama da UML, inclusive outros pacotes. Mais
comumente utilizado em Diagrama de Casos de Uso e Diagrama de Classes.
94
AUTOATIVIDADE
1 Em relação aos relacionamentos abaixo, responda:
a) Qual a representação mais correta – a primeira ou a segunda relação? Por

quê?
class Casa
Casa Pessoa
é propriedade
0..* 1
Casa Pessoa
+propriedade +proprietário
1..* 0..*
FONTE: Disponível em: <http://www.dainf.cefetpr.br/~tacla/UML/0070-DiagClasses-

ExerciciosSol.pdf>. Acesso em: nov. 2015.
b) Qual a diferença de interpretação entre as duas representações? Qual seria a

mais indicada para um tribunal eleitoral regional?
class eleições
eleitor 0..* eleitor 0..*
Pessoa Pessoa
vota>
candidatoPresidente candidatoPresidente
0..1 0..1
FONTE: Disponível em: <http://www.dainf.cefetpr.br/~tacla/UML/0070-DiagClasses-

ExerciciosSol.pdf>. Acesso em: nov. 2015.
2 Represente um e-mail na forma de Diagrama de Classes. Identifique os

componentes (destinatário, assunto etc...) e suas relações.
3 Qual a diferença de interpretação entre os relacionamentos livro-sobrecapa

e livro-páginas?
95
Livro 1...* Pagina 1...* Paragrafo
0..1
SobreCapa
4 Todo aluno matriculado em trabalho de diplomação será orientado por um

professor. Alguns professores orientam vários alunos e outros, nenhum.
Qual dos diagramas melhor representa esta relação?
Aluno Prof Aluno Prof

1 0..* 0..* 1
a) c)
orientador orientador
Aluno Prof Aluno Prof

0..* 1 1 0..*
b) d)
orientador orientador
5 Construa a hierarquia de classes para os seguintes tipos de obras: romance,

livro de ficção, livro de autoajuda, gibi, rock, filme ficção, comédia e MPB.
6 Defina pacotes.
96
UNIDADE 2 TÓPICO 3
DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE

COMPONENTES
1 INTRODUÇÃO
Este diagrama está amplamente associado ao Diagrama de Classes.
Na verdade, o Diagrama de Objetos é praticamente um complemento do

Diagrama de Classes, sendo bastante dependente deste. O Diagrama de Objetos
fornece uma visão dos valores armazenados pelos objetos de um Diagrama de
Classes em um determinado momento da execução de um processo.
De acordo com Guedes (2011), o Diagrama de Objetos está amplamente

associado ao Diagrama de Classes, podendo ser visto como uma instância de tal
diagrama, assim como os objetos são instâncias de classes. Tal qual o Diagrama
de Classes, o Diagrama de Objeto é formado por estruturas estáticas. Bezerra
(2007) diz que um Diagrama de Objetos exibe uma fotografia do sistema em
um determinado momento, exibindo ligações formadas entre objetos conforme
interação entre eles e de acordo com valores de atributos.
Os Diagramas de Objetos abrangem a visão estática de projeto ou visão

estática de processo de um sistema (BOOCH; RUMBAUGH; JACOBSON, 2005).
2 PRINCIPAIS COMPONENTES: OBJETOS, RELACIONAMENTOS

Este diagrama nos dá uma visão de como ficarão os objetos em determinado
momento da execução do sistema. É como se tirássemos uma fotografia do sistema
em um momento para analisar os dados e os relacionamentos envolvidos.
97
FIGURA 50 – DIAGRAMA DE OBJETOS
cart:Cartao prod:Produto
- nroCartao=123 - codigo:|- d
- datainicioUso= - descricao=Leite:
23/12/208 Tipo A
- dataFimUso=null - quantidadeEstoque
=38
- vllUnitarioVenda
= 2.65
- estoqueMinimo=
30.00
- situacao=|
comp:Compra itl:llemCompra
- dataCompra= - qualidade=3.00
27/10/2009 - data Registro=
- valorTotal=12.80 itl:llemFornece
27/10/2009
- terminada=true - horaRegistro=12:05 - produto=prod
- recebidoPor=func - atendidoPor.func - quantidade=4.00
- cliente=cart - valorUnitario=2.83
func:Funcionamento fornec:Fornece fornec:Fornece

- cpf=123.456.789-01 - dataEntrada: - codigo=46
- nome=Olavo Petronio 27/10/2009 - nome=Fulano de
Caz - nroNF=123 Tal Ltda
- nroCarteiraProfissional - valorTotal=483.17 - cnpj=12.345.678/
= 12345 - lancadoPor=func 0009-10
- dataAdmissão= - dataLancamento=
13/05/1991 27/10/2009
- dataDemissao=null - horaLancamento=11:35
- senha=****** - fornecedor=forn
FONTE: Piva (2010)
Observe a notação desse diagrama: o objeto possui a mesma estrutura

de uma classe, porém seu nome vem antes do nome da classe. func: Funcionario
quer dizer objeto func da classe funcionário.
Podemos assim analisar as relações entre os objetos em um determinado

ponto da execução do sistema.
98
TÓPICO 3 | DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE COMPONENTES
3 DIAGRAMA DE COMPONENTES
Booch, Rumbaugh e Jacobson (2005) narram que um Diagrama
de Componentes mostra a organização e as dependências entre os vários
componentes de um sistema. Um componente representa um módulo físico
do código. As dependências entre os componentes mostram como mudanças
em um componente podem causar mudanças em outros componentes. Este
diagrama fornece uma visão modelada entre os módulos do próprio código-
fonte, bibliotecas e formulários, arquivos de banco de dados e demais arquivos
de sistema. Além de determinar como cada um desses elementos estará disposto
na organização do sistema e como interagem entre si (GUEDES, 2011). Mostra a
organização e as dependências existentes em um conjunto de componentes; os
diagramas de componentes abrangem a visão estática de implementação de um
sistema (BOOCH; RUMBAUGH; JACOBSON, 2005).
O Diagrama de Componentes é um diagrama estrutural que nos ajuda

a analisar as partes do sistema que podem ser substituídas por outras que
implementem as mesmas interfaces (de entrada e/ou de saída) sem alterar o seu
funcionamento.
3.1 PRINCIPAIS COMPONENTES: COMPONENTES,

INTERFACES, CLASSES E RELACIONAMENTOS
Todo componente, geralmente, pode ser substituído por uma classe,
que implementa suas interfaces. Por isso é bastante difícil separar um do outro.
Mas costumamos utilizar o Diagrama de Componentes quando precisamos
documentar um componente que pode ser substituído no sistema.
Um claro exemplo de uso de componente e, consequentemente, do

Diagrama de Componentes no estudo de caso da padaria do senhor João, é a
representação da balança que pesa os produtos comercializados na padaria.
Como a balança vai interagir com os componentes do software,

alimentando o sistema com informações sobre o produto vendido, como
peso e valor, o senhor João poderá substituir a balança apenas por outra que
possibilite as mesmas interfaces, tanto de entrada quanto de saída.
FONTE: Disponível em: <http://dicasdeinformatica.xyz/diagramas-uml/>. Acesso em: nov. 2015.
99
FIGURA 51 – COMPONENTES DO DIAGRAMA DE PACOTES
Código do produto Código do produto,

e preço por quilo quantidade comparada
e preço por quilo.
Produto Balança itemCompra

BalançaProduto BalançaItemCompra
FONTE: Piva (2010)
Podemos aproveitar e definir as interfaces de entrada e saída da balança e

deixá-las documentadas nesse diagrama.
3.1.1 Componente
É uma parte do sistema que é física e substituível e que está em
conformidade com um conjunto de interfaces (fornecidas e/ou requeridas). Um
componente é parte do sistema e é reutilizável.
Os diagramas de componentes capturam a estrutura física da

implementação.
3.1.2 Objetivos
• Organizar o código-fonte (ambiente de desenvolvimento).
• Construir um release executável (ambiente de produção).
• Especificar componentes como base de dados etc.
• Contém componentes, interfaces e relações entre componentes.
• Os pacotes de componentes podem ser utilizados para modelar a arquitetura
física.
• Identificar as principais peças do sistema.
Um pedaço de software reutilizável, bem encapsulado e “facilmente”

substituível.
• São blocos (peças) que combinados constroem o sistema pretendido.

• A dimensão dos componentes não é homogênea, existindo, num mesmo
sistema, componentes de diferentes dimensões.
• Quais são os bons candidatos a serem componentes do sistema?
• Itens que desempenham uma funcionalidade que é utilizada recorrentemente
no sistema. Exemplos: componentes de logging, parsers de XML, componentes
de gestão de carrinhos de compra (shopping carts) etc.
100
• Em UML um componente pode efetuar as mesmas funcionalidades que uma

classe faz:
o Generalização
o Associação com outros componentes ou classes
o Implementação de interfaces
• Um componente representa um empacotamento físico de elementos

relacionados logicamente (normalmente classes).
FONTE: Disponível em: <http://slideplayer.com.br/slide/1584624/>. Acesso em: nov. 2015.
Os componentes existem no mundo material, de bits. São um elemento

importante na modelagem dos aspectos físicos de um sistema. Um
componente é uma parte física e substituível de um sistema, que
realiza um conjunto de interfaces. Exemplos de componentes são
código-fonte, executáveis, bibliotecas, tabelas, arquivos e documentos.
Um componente, tipicamente, é uma versão física de elementos
lógicos, como classes e interfaces. Disponível em:
<http://www.cin.ufpe.br/~eng_soft/eti901/NotasdeAulas/a8_1-
UMLImplementacao.pdf>. Acesso em: nov. 2015.
Diagramas de componentes são usados para modelar os aspectos

físicos de um sistema: o código-fonte de um aplicativo, uma API
etc. Nos Diagramas de Componentes são mostrados componentes e
os relacionamentos entre eles. Dependências entre componentes são
mostradas. A única restrição é que o que está sendo modelado deve
ser físico (formado por bits) e não conceitual (ou lógico). Disponível
em: <http://slideplayer.com.br/slide/3691521/>. Acesso em: nov. 2015.
Na UML 2
• Uma parte modular de um sistema que encapsula seu conteúdo e cuja

manifestação seja substituível dentro de seu ambiente.
• Um componente define seu comportamento em termos de interfaces fornecidas
e requeridas.
3.1.3 Diagrama de Componentes

• Especificação de um conjunto de componentes e suas interdependências.
• Representam de forma estática aspectos físicos do sistema que está sendo
modelado.
• São importantes para visualizar, especificar e documentar sistemas baseados
em componentes.
• Eles mostram um conjunto de componentes e seus relacionamentos.
• São tipicamente usados para:
101
o Modelar a organização do código-fonte.

o Modelar lançamento de executáveis (release).
o Modelar fisicamente um banco de dados.
o Modelar sistemas adaptativos.
o Modelar a organização do código-fonte.
• Na implementação das classes definidas durante a modelagem, o código

gerado será armazenado fisicamente em arquivos, o Diagrama de
Componentes serve como forma de gerenciamento destes arquivos.
o Modelar lançamento de executáveis (releases).
• Uma versão de um sistema envolve combinações específicas de diversas

partes. O Diagrama de Componentes pode modelar os diversos componentes
necessários para uma determinada versão do sistema.
o Modelar fisicamente um banco de dados.
• Considerando-se que as informações do sistema serão armazenadas em

arquivos ou tabelas de um banco de dados, um Diagrama de Componentes
pode mostrar os arquivos (ou tabelas) do banco de dados e seus
relacionamentos.
o Modelar sistemas adaptativos.
• A execução de alguns sistemas baseia-se no uso de componentes dinâmicos

(carga dinâmica, agentes móveis etc.), que podem ser descritos através de um
Diagrama de Componentes conjuntamente com outros diagramas da UML.
• O principal elemento sintático deste diagrama é o componente.
• O principal objetivo deste diagrama, segundo Scott Ambler, é possibilitar a
construção de artefatos para o perfil de arquitetura da solução, seja para a
arquitetura técnica ou a de negócios.
FONTE: Disponível em: <https://www.google.com.br/url?sa=t&rct=j&q=&esrc=s&source=web&c

d=1&cad=rja&uact=8&ved=0ahUKEwiVn9CI2J_JAhVGPZAKHSE2AwUQFggeMAA&url=http%3
A%2F%2F200.17.137.109%3A8081%2Fnovobsi%2FMembers%2Fgiordano%2Faulas%2F2010.2%2F
modelagem-e-programacao-orientada-a-objetos%2FDiagrama%2520de%2520Componentes.
pptx&usg=AFQjCNHjrdTLZ5fjTY_uQhdE5xZC1z0nIA>. Acesso em: nov. 2015.
102
Uma reflexão sobre Banco de Dados Orientados a Objetos
Clodis Boscarioli
Anderson Bezerra
Marcos de Benedicto
Gilliard Delmiro
Até meados dos anos 60, os dados eram mantidos aleatoriamente em

arquivos, geralmente como partes integrantes da aplicação. A partir dessa época,
surgiram os primeiros Sistemas Gerenciadores de Bancos de Dados (SGBDs)
comerciais, provendo armazenamento dos dados de forma independente da
aplicação, contudo, sem mecanismos de acesso eficientes.
Codd (1970) propôs a criação de linguagens de alto nível, permitindo

manipulação eficiente. A partir dos anos 80 as aplicações computacionais
evoluíram, juntamente com o poder de processamento das máquinas, surgindo
a necessidade de tratar dados mais complexos, não convencionais. Devido a
esse aumento na complexidade dos dados, surgiu a necessidade de formas
mais adequadas de representação e armazenamento, como as bases de dados
orientadas a objetos.
Durante a década de 80, como resultado das inovações de hardware,

emergiram novas aplicações com utilização intensiva de dados. Para essas
aplicações, os modelos de dados tradicionais, baseados no modelo relacional, não
eram adequados. Alguns exemplos de aplicações desse tipo incluem sistemas de
design e produção, como CAD (Computer-Aided Design) e CAM (Computer-
Aided Manufacturing), sistemas para as áreas científica e médica, sistemas de
informação geográfica e bases de dados com informações multimídia. Essas
aplicações possuem requisitos e características, tais como dados altamente
estruturados, transações longas, dados em multimídia e operações fora do padrão,
específicas da aplicação, que as tornam diferentes das aplicações tradicionais
(CHAUDRI & ZICARI, 2001, p. 3).
Silberchatz et al. (2001, p. 307) afirmam que:
À medida que as bases de dados foram sendo utilizadas em um âmbito

maior de aplicações, as limitações impostas pelo modelo relacional
emergiram como obstáculos. Como resultado, pesquisadores da
área de bancos de dados inventaram novos modelos de dados que
superassem as restrições do modelo relacional. [...] Nos últimos anos a
demanda por maneiras de tratar dados mais complexos tem crescido.
Existe um grande interesse relativo às tecnologias orientadas a objetos na

comunidade de desenvolvimento de software, sobretudo no tocante à facilidade de
alteração de implementações de acordo com mudanças solicitadas nos requisitos.
103
A capacidade que esse paradigma possui de representar dados complexos uniu-

se à tecnologia de banco de dados, gerando os Bancos de Dados Orientados a
Objeto (BDOO), que suportam modelagem e criação de dados como objetos
(ODBMS, 2006). O objetivo desse artigo é prover uma visão geral sobre sistema
de BDOO, uma tecnologia não tão nova (BANCIIHON, 1988; ATKINSON, et al.,
1989), contudo considerada ainda pouco explorada. Para tal, está organizado
como segue: Conceitos básicos sobre Banco de Dados Relacionais (BDR) e BDOO
são abordados na Seção 2. A Seção 3 diz respeito à modelagem no paradigma
orientado a objetos, mostrando como um mesmo modelo pode ser usado em
ambas as camadas, de banco de dados e da aplicação.
2 Bancos de Dados Relacionais versus Bancos de Dados Orientados a Objetos
BDRs e BDOOs possuem características distintas, mas basicamente

servem ao mesmo propósito: persistir dados necessários para a manutenção do
negócio para o qual são aplicados, possibilitando a recuperação, comparação e
tratamento desses dados a fim de produzir resultados tangíveis. Em BDR, uma
coleção de tabelas, todas com nomes únicos, compõe a base de dados, podendo
estar relacionada a uma ou mais tabelas. Conceitos como integridade referencial
de dados – que garantem que um dado referenciado em uma tabela esteja presente
na tabela que está sendo referenciada – e chaves primárias estão presentes e
garantem que um conjunto de informações possa ser representado de maneira
consistente, independente da forma de acesso.
Já um BDOO possui três pilares principais: herança, polimorfismo e

encapsulamento, discutidos a seguir. Este modelo apresenta maior flexibilidade na
manipulação de seu conteúdo e, por meio de identificadores de objetos, manipula os
dados de forma consistente. Silbeschatz et al. (2001) concluem que as bases de dados
tradicionais são bastante eficientes para tarefas ligadas ao processamento de dados. A
geração de folhas de pagamento e o gerenciamento de contas correntes são exemplos.
Esse tipo de aplicação trabalha basicamente com tipos de dados simples: numéricos,
texto e datas. Além disso, essas aplicações possuem itens de dados que podem ser
representados como registros razoavelmente pequenos e campos atômicos.
Apesar do conceito de bancos de dados orientados a objetos ser bastante

distinto do modelo relacional, o mesmo resulta da integração entre a orientação a
objetos e a tecnologia de banco de dados tradicionais. Enquanto na programação
orientada a objetos, os objetos existem apenas enquanto o programa que os criou
está em execução, os bancos de dados orientados a objetos podem criar objetos
que sejam persistentes e compartilhados entre diferentes aplicativos.
[...]
4 Principais SGBDOOs no Mercado Atual
Os sistemas gerenciadores de bancos de dados orientados a objetos não

possuem grandes discrepâncias em termos de funcionalidades exigidas quando
relacionados aos SGBDs relacionais. Entretanto, torna-se necessário levantar
104
alguns pontos de diferenciação. Uma das principais exigências de um SGBDOO é
o armazenamento de objetos e suas operações de forma a prover uma integração
transparente com a aplicação, sem a necessidade de uma camada de tradução dos
dados. A Tabela 1 traz uma comparação entre três grandes SGBDOOs disponíveis
no mercado, o Objectivity/DB, o GemStone e o Jasmine, evidenciando que suas
funcionalidades não diferem muito com relação aos aspectos mais importantes
dos SGBDOOs.
Para Chaudri & Zicari (2001), a oferta de SGBDOOs tem aumentado,

principalmente, como consequência do crescimento da utilização da plataforma
Java. O mesmo afirmam Dan Lo et al. (2002). Segundo estes autores, o impacto
desta linguagem de programação no mundo dos SGBDOOs tem sido considerável
e diversos SGBDOOS realizaram modificações para oferecer suporte nativo
para o armazenamento de objetos Java. Ferramentas como POET e ObjectStore,
inicialmente desenvolvidas para persistência de objetos C++, disponibilizaram
versões com capacidade de persistir objetos Java. Como resultado do aumento
da popularidade do desenvolvimento de sistema em Java, a segunda versão
do padrão ODMG adicionou elementos de ligação Java. Isto também refletiu
em algumas mudanças no modelo de objetos, como a noção de interface e a
introdução de dois tipos diferentes de hierarquias.
Principais SGBDOOOs do mercado

Open Sistema
Nome Fabricante Site Oficial
Source Operacional
Linux, MacOs,
EntrepriseDB SIM Solaris e EnterpriseDB http://www.enterprisedb.com/
Windows
Linux, Objectivity
Objectivity/DB NÂO Windows e Database http://www.objectivity.com
Unix Posix Systems
WIndows, GemStone
GemStone NÂO http://www.gemsotne.com
UNIX e Linux System Inc.
WIndows e
ConteXT NÃO Unixspace http://www.contextsoft.com/
UNIX
Windows,
Versant NÃO Versant Corp. http://www.versant.com
Linux e UNIX
Windows, Intersystems
Caché NÃO http://www.intersystems.com.br
Linux e UNIX Software
Sysra
EyeDB SIM Linux e UNIX http://www.eyedb.org/
Informatique
Windows, Computer
Jasmine NÃO http://www.3.ca.com/
Linux e UNIX Associates
Orion Group
ORION SIM Linux e UNIX (Purdue http://orion.cs.purdue.edu/
University)
Windows, Progress
ObjectStore NÃO http://www.objectstore.com
Linux e UNIX Software
105
5 Tendências
Algumas tendências referentes à orientação a objetos aplicada a bancos

de dados estão sendo discutidas há certo tempo, sem terem amadurecido muito
nesse período. Existe hoje a possibilidade de avaliar quais tendências serão de
fato concretizadas, levando em consideração o histórico da tecnologia? Entre as
tendências emergentes neste contexto está o armazenamento em memória. Um
exemplo de armazenamento em memória é o Prevayler (2006).
Produzido independentemente por um grupo de brasileiros, essa

ferramenta consiste em um repositório de objetos com desempenho de acesso
bastante superior aos bancos de dados tradicionais, principalmente pela
característica de manter os objetos em memória no servidor de aplicações. Essa
tecnologia ainda tem limitações, principalmente ligadas à recuperação dos dados
em caso de falha e aumento da necessidade de memória. Existem, e bem aceitos
no mercado atual, os sistemas de banco de dados objeto-relacionais. Estes podem
ser vistos como uma tentativa de estender sistemas de banco de dados relacionais
com funcionalidades dos bancos de dados orientados a objetos, necessárias para
dar suporte a uma classe mais ampla de aplicações e, de certa forma, prover uma
ligação entre esses paradigmas.
Além dos sistemas gerenciadores de banco de dados objeto-relacionais,

como Oracle (2006) e PostgreSQL (2006), já bastante difundidos no mercado, outra
tendência são as interfaces objeto-relacionais que consistem em uma abstração
do modelo relacional para uma camada que provê interface de banco de dados
orientado a objetos para uma aplicação e pode ser exemplificada por ferramentas
como o Hibernate (2006). Essa tecnologia permite que as aplicações persistam os
dados de forma transparente em quaisquer tipos de bancos, inclusive arquivos-
texto, cuidando de toda a complexidade inerente à tarefa.
Para a aplicação é como se existisse um banco de dados orientado a objeto

servindo de repositório. As novas arquiteturas orientadas a serviço, como a
SOA (Service Oriented Architecture) (GUPTA, 2005; COHEN, 2006), também estão
forçando os desenvolvedores a produzirem sistemas com um aproveitamento
cada vez maior de componentes e, consequentemente, com menor acoplamento.
Por esse motivo, as bases de dados relacionais, onde até o momento os dados são
persistidos, deixam de atender a esse tipo de requerimento, tornando as bases de
dados orientadas a objetos uma escolha mais interessante para uma escala ainda
maior de aplicações.
Com isso, a possibilidade do surgimento de novas tecnologias ligadas

ao paradigma da orientação a objeto, que tenham como missão auxiliar na
persistência dos dados de cada um dos objetos, tende a crescer nos próximos
anos.
106
RESUMO DO TÓPICO 3
• O Diagrama de Objetos está amplamente associado ao Diagrama de Classes. Na

verdade, o Diagrama de Objetos é praticamente um complemento do Diagrama
de Classes, sendo bastante dependente deste.
• Os Diagramas de Objetos abrangem a visão estática de projeto ou visão estática

de processo de um sistema.
• Este diagrama nos dá uma visão de como ficarão os objetos em determinado

momento da execução do sistema.
o Principais componentes: objetos, relacionamentos.
• O Diagrama de Componentes é um diagrama estrutural que nos ajuda a analisar

as partes do sistema que podem ser substituídas por outras que implementem as
mesmas interfaces (de entrada e/ou de saída) sem alterar o seu funcionamento.
o Principais componentes: componentes, interfaces, classes e relacionamentos.

o Objetivos:
o Organizar o código-fonte (ambiente de desenvolvimento).
o Construir um release executável (ambiente de produção).
o Especificar componentes como base de dados etc.
o Contém componentes, interfaces e relações entre componentes.
o Os pacotes de componentes podem ser utilizados para modelar a arquitetura
física.
o Identificar as principais peças do sistema.
107
AUTOATIVIDADE
1 Defina Componente.
2 Quais as vantagens/motivações para a construção de modelos de

componentes?
3 Defina Diagrama de Objetos.
108
UNIDADE 3
DIAGRAMAS ESTRUTURAIS
Ao final desta unidade você será capaz de:
• conhecer os diagramas estruturais de implantação e estrutura composta;
• ter uma visão da integração dos diagramas;
• conhecer as principais ferramentas UML.
PLANO DE ESTUDOS
Esta unidade de ensino contém três tópicos e no final de cada um deles você
TÓPICO 1 – DIAGRAMAS DE IMPANTAÇÃO E ESTRUTURA COMPOSTA
TÓPICO 2 – INTEGRAÇÃO DOS DIAGRAMAS – UMA VISÃO GERAL DO

DESENVOLVIMENTO USANDO UML
TÓPICO 3 - ESTUDO DE CASO
109
110
UNIDADE 3
TÓPICO 1
DIAGRAMA DE IMPLANTAÇÃO E ESTRUTURA COMPOSTA
1 INTRODUÇÃO
Os Diagramas de Implantação mostram a topologia do sistema em
tempo de execução, representando a configuração e a arquitetura do mesmo
em relação aos seus componentes (BOOCH; RUMBAUGH; JACOBSON, 2006).
Ainda, na percepção dos autores, este tipo de diagrama modela a visão estática
da implantação do sistema, expressando o conjunto de hardware e demais
tecnologias físicas relacionadas com sua instalação. Também podem ser usados
para especificar os módulos do sistema que deverão ser instalados no cliente.
Estes diagramas são compostos por nós e associações, mais conhecidos

como relacionamentos de comunicação. Os nós podem ser reconhecidos como
sendo um computador, uma rede, um HD. Diagramas de Implantação são mais
utilizados por equipes de desenvolvimento, integração e testes. Também são
usados para mapear os programas que são executados em cada computador.
FIGURA 52 – EXEMPLO DE DIAGRAMA DE IMPLANTAÇÃO
FONTE: Disponível em: <http://www.cin.ufpe.br/~eng_soft/eti901/NotasdeAulas/a8_1-

UMLImplementacao.pdf:>. Acesso em: 20 out. 2015.
111
UNIDADE 3 | DIAGRAMAS ESTRUTURAIS
FONTE: Disponível em: <http://www.cin.ufpe.br/~eng_soft/eti901/NotasdeAulas/a8_1-

UMLImplementacao.pdf:> Acesso em: 20 out. 2015.
2 PRINCIPAIS COMPONENTES
Os nós podem representar dispositivos computacionais, como um
computador ou um celular, ou um recurso de computação, como um sistema
operacional, quaisquer outros softwares que integrem a estrutura da aplicação.
Possuem um nome e podem receber um estereótipo. Um nó é representado por
um cubo. Os nós executam os artefatos.
Uma associação entre dois nós representa uma conexão física entre os nós,
como uma conexão Ethernet, uma linha serial ou um link de satélite.
Artefatos são os elementos executados pelos nós, geralmente os

programas da solução criada possuem um nome e podem possuir um estereótipo.
Os relacionamentos são utilizados para representar o tipo de ligação entre os
componentes do diagrama. Podem possuir estereótipos.
Veja que, na figura a seguir, demonstramos em detalhes a arquitetura da

solução proposta.
112
TÓPICO 1 | DIAGRAMA DE IMPLANTAÇÃO E ESTRUTURA COMPOSTA
<<sevidor>>
servidor web
<<banco operacional>>
:Linux
<<banco de aplicação>> <<web container>>
Computador Cliente <<HTTP>> :Tomcat
:Apache
<<navegador web>> <<artefato>>
:Internet Explorer :vendeTudo.war
<<10-T Ethernet>>
<<servidor>>
Servidor de Banco de Dados
<<sistema operacional>>
:windows server
<<banco de dados>>
:SQLServer
<<artefato>>
:vendeTudoBD
FONTE: Piva (2010)
3 DIAGRAMA DE ESTRUTURA COMPOSTA

O Diagrama de Estrutura Composta é utilizado para modelar
colaborações. Uma colaboração descreve uma visão de um conjunto de entidades
cooperativas interpretadas por instâncias que cooperam entre si para executar
uma função específica.
O termo estrutura se refere à composição dos elementos estruturais

interconectados de forma a atingir algum objetivo comum. O exemplo
acima mostra como as instâncias das classes autor, submissão, tema e tipo
colaboram entre si para submeter à submissão. As colaborações podem
também possuir multiplicidade, se as regras seguidas pelas classes utilizarem
múltiplas instâncias. Este é um diagrama que não é muito utilizado na UML e
provavelmente é mais um diagrama teórico do que um diagrama utilizado nos
processos de desenvolvimento.
FONTE: Disponível em: <http://www.novatec.com.br>. Acesso em: 5 nov. 2015.
113
Nos modelos UML, um Diagrama de Estrutura Composta mostra a

estrutura interna dos classificadores estruturados utilizando peças, portas
e conectores. Um classificador estruturado define a implementação de
um classificador e pode incluir uma classe, um componente ou um nó de
implementação. Você pode utilizar o Diagrama de Estrutura Composta para
mostrar os detalhes internos de um classificador e descrever os objetos e funções
que trabalham juntos para executar o comportamento do classificador contido.
FONTE: Disponível em: <http://www.novatec.com.br>. Acesso em: 5 nov. 2015.
Um Diagrama de Estrutura Composta é similar a um Diagrama de

Classes, mas ele representa peças individuais em vez de classes inteiras. Antes
de definir a estrutura interna de um classificador, você deve mostrar seu
compartimento de estrutura ou abrir um Diagrama de Estrutura Composta.
Então, você pode modelar as peças que representam as instâncias que o
classificador contido possui. Você pode incluir conectores para vincular duas
ou mais peças em um relacionamento de associação ou dependência.
Em Diagramas de Estrutura Composta, as portas definem o ponto de

interação entre um classificador e seu ambiente ou entre um classificador e
suas peças internas. Você pode utilizar uma porta para especificar os serviços
que um classificador fornece e requer de seu ambiente.
Você também pode modelar colaborações e usos de colaborações em

Diagramas de Estrutura Composta. Uma colaboração descreve as funções e os
atributos que definem um comportamento específico do classificador. Um uso
de colaboração representa um uso específico da colaboração para explicar os
relacionamentos entre as propriedades de um classificador. Para identificar as
funções das peças no uso de colaboração, você anexa um uso de colaboração a
uma colaboração e, em seguida, inclui o uso de colaboração em um diagrama
de estrutura composta.
FONTE: Disponível em: <http://www-01.ibm.com/support/knowledgecenter/SS5JSH_9.1.1/com.

ibm.xtools.modeler.doc/topics/ccompstruc.html?lang=pt-br>. Acesso em: nov. 2015.
Os seguintes tópicos descrevem elementos de modelo em Diagramas de

Estrutura Composta:
Peças
Em Diagramas de Estrutura Composta, uma peça é um elemento de

diagrama que representa um conjunto de uma ou mais instâncias que um
classificador estruturado contido possui. Uma peça descreve a função de uma
instância em um classificador. Você pode criar peças no compartimento de
estrutura de um classificador e em vários diagramas UML, como estrutura
composta, classe, objeto, componente, implementação e Diagramas de Pacote.
114
TÓPICO 1 | DIAGRAMA DE IMPLANTAÇÃO E ESTRUTURA COMPOSTA
Portas
Em Diagramas de Estrutura Composta, uma porta define o ponto

de interação entre uma instância do classificador e seu ambiente ou entre o
comportamento do classificador e suas peças internas.
Colaborações
Nos diagramas UML, uma colaboração é um tipo de classificador

estruturado no qual as funções e atributos cooperam para definir a estrutura
interna de um classificador. Você utiliza uma colaboração quando deseja
definir apenas as funções e conexões que são requeridas para executar um
objetivo específico da colaboração. Por exemplo, o objetivo de uma colaboração
pode definir as funções ou os componentes de um classificador. Ao isolar
as funções principais, uma colaboração simplifica a estrutura e esclarece o
comportamento em um modelo.
Usos de Colaboração
Nos Diagramas de Estrutura Composta, um uso de colaboração é um

elemento de modelo que representa um uso de uma colaboração para explicar
os relacionamentos entre as partes de um classificador estruturado. Você
utiliza um uso de colaboração para aplicar um padrão, que é descrito por uma
colaboração, para uma situação específica que envolve classes ou instâncias
que desempenham as funções de colaboração especificadas. Você pode ter
vários usos de colaboração, cada um envolvendo um conjunto diferente de
funções e conectores para uma colaboração determinada.
Conectores em Classificadores Estruturados
Em diagramas UML, um conector é uma linha que representa um

relacionamento em um modelo. Ao modelar a estrutura interna de um
classificador, você pode utilizar um conector para indicar um link entre duas
ou mais instâncias de uma peça ou porta. O conector define o relacionamento
entre os objetos ou instâncias que são ligados a funções no mesmo classificador
estruturado e identifica a comunicação entre essas funções. O produto
especifica automaticamente o tipo de conector a ser criado
FONTE: Disponível em: <http://www-01.ibm.com/support/knowledgecenter/SS5JSH_9.1.1/com.

ibm.xtools.modeler.doc/topics/ccompstruc.html?> Acesso em: 21out. 2015.
115
FIGURA 55 – EXEMPLO DE DIAGRAMA DE ESTRUTURA COMPOSTA

IU do controle da TV
multiplicidade
Visualizador
de TV
parte 1
controles:
ApresentadordeTV
conector de delegação
conector
tela
:Gerador [1]
API do controle da TV
sintonia fluxo de imagens
FONTE: Disponível em: <http://regissimao.com.br/wp-content/uploads/2014/03/

UML-08-Diagrama-de-Estruturas-Compostas.pdf>. Acesso em: 23 out. 2015.
116
RESUMO DO TÓPICO 1
• O Diagrama de Implantação representa a configuração e a arquitetura do

sistema em que estarão ligados os respectivos componentes. Booch, Rumbaugh
e Jacobson (2006) dizem que este diagrama exibe a configuração dos nós de
processamento em tempo de execução e os componentes que nele existem.
• Neste diagrama também pode ser representada toda a estrutura de hardware

e requisitos mínimos onde o sistema será executado. Este diagrama modela a
visão estática da implantação de um sistema. Dado um determinado sistema
de software, o Diagrama de Implantação vai expressar o conjunto de hardware e
toda a tecnologia física relacionada com a instalação do sistema. Os Diagramas
de Implantação também podem ser usados para especificar os módulos do
sistema que deverão ser instalados no cliente.
• São usados para modelar a topologia do ambiente no qual o software será

executado.
• São compostos por nós e associações (relacionamentos de comunicação).
• Um nó pode ser, por exemplo, um computador, uma rede, um disco rígido,

um sensor etc. Usado para as equipes de: desenvolvimento, integração e testes.
Também mapeiam como os componentes são distribuídos na arquitetura física.
• O Diagrama de Estrutura Composta é utilizado para modelar colaborações.

Uma colaboração descreve uma visão de um conjunto de entidades cooperativas
interpretadas por instâncias que cooperam entre si para executar uma função
específica.
• O termo estrutura se refere à composição dos elementos estruturais

interconectados de forma a atingir algum objetivo comum. O exemplo
acima mostra como as instâncias das classes autor, submissão, tema e tipo
colaboram entre si para submeter à submissão. As colaborações podem
também possuir multiplicidade, se as regras seguidas pelas classes utilizarem
múltiplas instâncias. Este é um diagrama que não é muito utilizado na UML e
provavelmente é mais um diagrama teórico do que um diagrama utilizado nos
processos de desenvolvimento.
117
AUTOATIVIDADE
1 É empregado para a modelagem dos aspectos físicos de um sistema OO.

Mostra a configuração dos nós de processamento em tempo de execução e
os artefatos que nele existem. Trata-se do diagrama de:
a) Comunicação
b) Componentes
c) Implantação
d) Estrutura Composta
FONTE: Disponível em: <https://www.qconcursos.com/questoes-de-concursos/questao/22b

e5843-46>. Acesso em: nov. 2015.
2 Considere C = comportamental e E = estrutural. Os diagramas de componentes,

objetos, comunicação e estrutura composta são, respectivamente,
categorizados como:
a) C; C; E; C
b) C; C; E; E
c) E; E; C; E
d) E; E; C; C.
FONTE: Disponível em: <https://www.qconcursos.com/questoes-de-concursos/questao/22b

e5843-46>. Acesso em: nov. 2015.
118
UNIDADE 3
TÓPICO 2
INTEGRAÇÃO DOS DIAGRAMAS – UMA VISÃO GERAL DO

DESENVOLVIMENTO USANDO UML
1 INTRODUÇÃO
Neste tópico, será apresentada uma situação real tendo como cenário uma
padaria. Com isso, será possível visualizar de forma bem clara a interação de
vários diagramas e a sequência de criação dos mesmos.
2 EXEMPLO DE DESENVOLVIMENTO DE PROJETOS USANDO

UML
Geralmente, desenvolvemos os diagramas de casos de uso para
agrupar as funcionalidades mais importantes a serem implementadas. Sobre
tais funcionalidades criamos o Diagrama de Classes, que será a estrutura de
nossa aplicação ou o que chamamos de classes de projeto. No caso de uma
padaria, por exemplo, as classes de projeto são as classes de cliente, produto,
funcionário, compra, fornece e suas classes filhas.
Definimos seus principais atributos e então fazemos o Diagrama de

Sequência para os casos de uso mais relevantes – no exemplo da padaria, os
casos de uso registrar compra, pagar compra, receber mercadoria. Usamos
esse diagrama para definir os principais métodos de nossas classes e as trocas
de mensagens entre elas. Com isso definido, voltamos ao Diagrama de Classes
e o complementamos com os métodos definidos nos Diagramas de Sequência.
Começamos então a nos preocupar com a interface e com o usuário

e escolhemos quais formulários serão necessários para o funcionamento
de nossa aplicação. Com as classes definidas, começamos a separá-las para
melhor organizar a aplicação.
Utilizamos para isso o padrão MVC. Esse padrão, muito utilizado

pelos desenvolvedores orientados a objeto, foi criado com a linguagem de
programação Smalltalk80. Consiste basicamente em dividir as classes da
aplicação em três grupos, que chamamos de model, view e controller. Criamos
um pacote para cada um desses itens. No model, em geral, inserimos as classes
de projeto, seguindo o modelo de nossa aplicação.
119
No view criamos as classes de interface com o usuário (telas) e no

controller inserimos as classes que implementarão as funcionalidades de cada
classe, desde uma simples consistência até o acesso ao banco de dados. Essas
classes que implementam o acesso ao banco de dados levam o nome de classes
de persistência, muitos desenvolvedores as colocam em outro pacote.
Dentro do view voltamos a separar as classes em pacotes para

implementar a modulação do sistema, criando pacotes para cadastro,
movimentação, consultas, relatórios e demais rotinas da execução do sistema,
às quais chamamos de ferramentas. Com isso organizamos internamente as
classes nos mesmos padrões utilizados na aplicação.
Terminada a separação das classes, criamos os diagramas de atividade

para os casos de uso cujo procedimento e funcionamento pretendemos deixar
documentados.
Verificamos então se é necessário documentar as interfaces de algum

componente de software e elaboramos diagramas de componentes para isso.
Se houver classes que mudam de estado no decorrer da execução do sistema,
desenvolvemos o Diagrama de Máquinas de Estados para demonstrar qual a
ideia da mudança de estado para cada uma delas.
Por fim, se o ambiente de implantação for um ambiente heterogêneo,

isto é, que envolve arquitetura com vários servidores, como servidor de
banco de dados e servidor de aplicações, entre outros, criamos o Diagrama
de Implantação para demonstrar a arquitetura de software e hardware onde a
aplicação deverá ser instalada.
Veja que nessa forma de desenvolvimento utilizamos os diagramas de

casos de uso, os de classes, os de sequência, os de pacotes, os de atividades,
os de máquina de estados, os de componentes e o de implantação. Tudo
depende do tamanho da aplicação a ser desenvolvida e das dificuldades que
encontramos nas fases de análise e projeto de software.
É comum também surgirem alterações nos modelos na fase de

programação do software. Nesse caso, voltamos ao modelo e incluímos as
alterações que fizemos na fase de programação e testes. Mesmo depois de
implantada a solução, sempre que for necessário fazer alguma alteração no
sistema, devemos voltar ao modelo e fazer a inclusão, para que o modelo
nunca fique diferente do sistema criado.
FONTE: Piva (2010, p. 164)
120
TÓPICO 2 | INTEGRAÇÃO DOS DIAGRAMAS – UMA VISÃO GERAL DO DESENVOLVIMENTO USANDO UML
Verifique a situação no Diagrama de Visão Geral, proposto abaixo.
FIGURA 56 – DIAGRAMA DE VISÃO GERAL
121
FONTE: Piva (2010)
122
RESUMO DO TÓPICO 2
Neste tópico você:
• Visualizou a interação entre todos os diagramas envolvidos em uma modelagem

orientada a objetos.
123
AUTOATIVIDADE
1 Descreva os passos para a visualização da integração dos diagramas.
124
UNIDADE 3
TÓPICO 3
ESTUDO DE CASO
1 INTRODUÇÃO
Uma empresa é formada por um conjunto de processos inter-
relacionados. Logo, o aumento da eficiência da empresa deve ser obtido em
função da compreensão e melhoria destes processos. Um processo dispõe de
inputs, outputs, tempo, espaço, ordenação, objetivos e valores que, interligados
logicamente, irão resultar em uma estrutura para fornecer produtos ou serviços
ao cliente. Quase toda a operação de uma empresa pode ser traduzida como
um conjunto harmônico de processos e subprocessos que interagem para que
os produtos e serviços sejam entregues com eficiência, qualidade e nos prazos
desejados pelos clientes.
Todos os processos podem (e devem) ser melhorados ao longo do

tempo para que os resultados sejam cada vez mais satisfatórios. Segundo
Barbalho et al. (2002), um dos principais requisitos para o tratamento adequado
de processos de negócio é sua efetiva compreensão, pois estando dispersos por
várias áreas funcionais, é necessário que o gestor do processo conheça muito
bem seus limites e abrangência.
Tal questão pode ser tratada com sucesso através da modelagem de

processos, existindo até então diversas abordagens que se propõem a realizar
tal intento. Faremos um estudo de caso aplicando a Linguagem de Modelagem
Unificada (UML – em inglês Unified Modeling Language) para modelar um
processo de negócio. A UML já é considerada um padrão para o modelamento
de sistemas de informação, e caminha para especificações cada vez mais
consistentes acerca do modelamento de processos de negócio.
FONTE: Disponível em: <http://www.abepro.org.br/biblioteca/enegep2008_tn_sto_069_496_11902.

pdf>. Acesso em: nov. 2015.
125
FONTE: Disponível em: <http://www.abepro.org.br/biblioteca/enegep2008_tn_

sto_069_496_11902.pdf>. Acesso em: 10 nov. 2015.
2 NECESSIDADE DE COMPREENDER OS PROCESSOS DA

ORGANIZAÇÃO
O mapeamento de processos é útil para as empresas manterem-se
competitivas através do contínuo aperfeiçoamento de seus processos, uma
vez que proporciona uma metodologia estruturada para a busca da melhoria
contínua. Segundo Hammer et al. (1999), a gestão por processos de negócio para
as organizações aparece como alternativa vantajosa, desde que as ferramentas
126
TÓPICO 3 | ESTUDO DE CASO
para análise e mapeamento dos processos sejam de domínio do corpo técnico

e gerencial da organização. O conhecimento dos processos de negócio evolui
de forma contínua e altera consideravelmente a visão da organização, baseada
em conceitos tradicionais que fragmentam as tarefas por níveis hierárquicos e
por áreas funcionais.
Werneck et al. (2003) afirmam que a gestão por processos permite às

empresas uma melhor visibilidade das atividades, o que propicia ações que
promovam maior desempenho no fornecimento de seus produtos ou serviços,
maior capacidade de adaptação a mudanças, uso otimizado de recursos e
possibilidade de aprendizado. O mapeamento dos processos gera um modelo
da realidade, permitindo analisar a estrutura e o comportamento da empresa,
comparar, simular e propor melhorias destes processos.
Dessa forma, o mapeamento contribui para uma melhor compreensão

das atividades da empresa e suas interações. Dentro deste contexto está a
proposta deste trabalho, que vai utilizar o Diagrama de Atividades da UML
para modelar e analisar um processo de negócio, usufruindo as vantagens
deste diagrama na representação das atividades do processo. Além disso, o
uso da UML permite aproximar a modelagem e a análise de processos com a
Engenharia de Sistemas.
2.1 O MAPEAMENTO DE PROCESSOS

Barbalho (2002) afirma que um importante elemento de um modelo
de processos de negócio é sua navegabilidade. Uma boa navegabilidade
significa que é possível a um usuário do modelo caminhar entre as visões
de uma maneira lógica, sem que seja necessário quebrar o raciocínio, mas ao
contrário, construindo uma teia de relações que permita uma visão holística
do processo modelado. Algumas técnicas de mapeamento de processo, como
o fluxograma, apresentam-se consagradas na literatura, porém, novas técnicas
de mapeamento estão sendo discutidas, dentro de suas limitações e alcances.
A seguir apresenta-se uma breve descrição das técnicas mais utilizadas para
mapeamento e análise de processos.
127
2.1.1 Fluxograma
O fluxograma é um gráfico que demonstra a sequência operacional do

desenvolvimento de um processo, que caracteriza: o trabalho que está sendo
realizado, o tempo necessário para sua realização, a distância percorrida
pelos documentos, quem está realizando o trabalho e como ele flui entre os
participantes deste processo.
O quadro a seguir mostra os principais símbolos utilizados pelos

profissionais de Processamento de Dados na elaboração de fluxogramas de
processo.
QUADRO 1 - NOTAÇÃO – SIMBOLOGIA BÁSICA
Terminal - símbolo utilizado como ponto para indicar o início e/ou fim do fluxo
de um programa.
Seta de fluxo de dados - permite indicar o sentido do fluxo de dados. Serve

exclusivamente para conectar os símbolos ou blocos existentes.
Processamento - símbolo ou bloco que se utiliza para indicar cálculos

(algoritmos) a efetuar, atribuições de valores ou qualquer manipulação de
dados que tenha um bloco específico para sua descrição.
Entrada de dados - utilizado para ler os dados necessários ao programa.
Decisão - indica a decisão que deve ser tomada, indicando a possibilidade de

desvios para diversos outros pontos do fluxo, dependendo do resultado de
comparação e de acordo com situações variáveis.
Conector - utilizado quando é preciso particionar o diagrama. Quando ocorrer

mais de uma partição, é colocada uma letra ou número dentro do símbolo de
conexão para identificar os pares de ligação.
O fluxograma originou-se a partir do aperfeiçoamento do diagrama de

blocos e do fluxograma utilizado na área de processamento de dados. Como
instrumento de múltiplas funções, o fluxograma, mediante sua representação
gráfica, permite visualizar e compreender melhor os processos de trabalho em
execução, as diversas fases operacionais, a interligação com outros processos e
todos os documentos envolvidos.
128
2.1.2 SADT (Structured Analysis and Design Technic)

O SADT “nasceu pelas mãos” de Douglas T. Ross num projeto de
desenvolvimento de uma linguagem estruturada para programação de máquinas-
ferramenta, no fim da década de 60. Este formalismo trazia algumas características
revolucionárias, como a decomposição funcional e o fato de ser baseado numa
representação esquemática simples, que auxiliou sobremaneira a descrição e o
desenvolvimento dos sistemas de software complexos que começavam a aparecer
(VERNADAT, 1996). Estas características disseminaram a aplicação deste formalismo
e também o seu desenvolvimento em direção a abordagens estruturadas completas
destinadas a diferentes aplicações, principalmente para a análise de sistemas.
O SADT e o IDEF0 são apresentados juntos, pois têm origens e uma

vida tão próximas que seus nomes até mesmo são fundidos na prática.
2.1.3 IDEF3
À medida que as técnicas de representação de processos foram evoluindo,
técnicas mais sofisticadas foram sendo aplicadas em processos de serviços. Um
bom exemplo é a aplicação do IDEF3. O IDEF3 é um dos integrantes da família
de técnicas IDEF (Integrated ComputerAided Manufacturing), que foi desenvolvida
pela Força Aérea dos Estados Unidos com o objetivo de descrever, especificar e
modelar sistemas de manufatura (ALMEIDA et al., 2003).
De modo geral, o IDEF3 fornece um mecanismo coletando e

documentando processos. Ele captura relações da precedência e de causalidade
entre situações e eventos em um formulário natural aos peritos do domínio,
fornecendo um método estruturado para expressar o conhecimento sobre
como um sistema ou um processo atua na organização. Segundo Costa (2002),
as descrições IDEF3 podem:
• Gravar os dados cruzando resultados das entrevistas fact-finding (fato-

encontrado) em atividades da análise dos sistemas.
• Determinar o impacto do recurso da informação de uma organização nos
cenários principais da operação de uma empresa.
• Documentar os procedimentos da decisão que afetam os estados e o ciclo
de vida de dados compartilhados críticos, particularmente manufaturar,
projetar, e dados da definição de produto da manutenção.
• Controlar a configuração dos dados e mudar a definição da política do
controle.
• Fazer o sistema projetar a análise do trade-off (fim de negócio).
• Fornecer a geração do modelo da simulação.
129
2.1.4 UML (Unified Modeling Language)

A UML está emergindo como a notação-padrão para modelagem,
sendo assim é importante compreendê-la. Segundo Furlan (1998), a UML vai
além de uma simples padronização em busca de uma notação unificada, uma
vez que contém conceitos novos que não são encontrados em outros métodos
orientados a objeto.
A UML é uma linguagem padrão para especificar, visualizar,

documentar e construir artefatos de um sistema e pode ser utilizada com todos
os processos ao longo do ciclo de desenvolvimento de software e através de
diferentes tecnologias de implementação. Alguns autores, como Wilcox et al.
(2003), defendem a utilização da UML, destacando as seguintes vantagens:
• Simplicidade nas notações.

• Alta padronização encontrada nas aplicações publicadas.
• Alta aplicabilidade nos processos reais.
• Notação flexível às diversas situações.
Para aplicação neste trabalho foi escolhida a UML, pois, como é uma
linguagem utilizada no desenvolvimento de software, seu uso se justifica no
sentido de integrar a análise do processo e a concepção do sistema (software).
2.1.5 Diagrama de Atividades

O modo para descrever os vários aspectos de modelagem pela UML é através
da notação definida pelos seus vários tipos de diagramas. Um diagrama é uma
apresentação gráfica de uma coleção de elementos de um modelo, frequentemente
mostrado como um gráfico conectado de arcos e vértices (FURLAN, 1998).
Os diagramas usados pela UML são: Diagrama de Casos de Uso,

Diagrama de Classes, Diagrama de Objetos, Diagrama de Gráfico de Estados,
Diagrama de Atividades, Diagrama de Sequências, Diagrama de Colaborações,
Diagrama de Componentes e Diagrama de Implantação.
Esses diagramas permitem a modelagem de todas as fases de um

projeto de software. Utilizaremos apenas o Diagrama de Atividades, que
é um diagrama de estado especial onde a maioria dos estados é estado de
ação e a maioria das transições é ativada por conclusão das ações nos estados
precedentes, mostrando o fluxo de uma atividade para outra.
Este diagrama é importante quando se pretende descrever um

comportamento paralelo, pois nem sempre os procedimentos se caracterizam por
130
uma sequência mecânica de passos. Um Diagrama de Atividades é essencialmente

um fluxograma que dá ênfase à atividade que ocorre ao longo do tempo.
Um Diagrama de Atividades é composto por:
• Início: Representado por um círculo preenchido.

• Estado de Atividade ou Atividade: Representado por um retângulo com
bordas arredondadas.
• Transição: quando uma atividade termina, o fluxo de controle passa
imediatamente para a atividade seguinte. Representado por uma linha
orientada.
• Desvio: Representado por um losango. Indica caminhos alternativos a tomar
em um diagrama, mediante alguma expressão.
• Intercalação: Também representado por um losango, é utilizada para marcar
o final de um comportamento condicional iniciado por um desvio, ou seja,
tem múltiplas entradas e uma única saída.
• Separação: Representado por um traço horizontal, quando temos
comportamento paralelo, ou seja, temos uma entrada e várias transições de
saída que são executadas em paralelo.
• Junção: Representado por um traço horizontal, utilizamos para completar a
separação, ou seja, quando temos um processamento paralelo, precisamos
sincronizar.
• Raias: Representada por retângulos que englobam todos os objetos que estão
ligados a um departamento. São usadas para indicar as entidades responsáveis pela
execução das atividades, em geral estruturas organizacionais. Com o conjunto de
elementos do Diagrama de Atividades é possível representar qualquer processo
que tenha como base uma sequência de atividades inter-relacionadas.
2.1.6 Aplicação do Diagrama de Atividades da UML

Para o estudo de caso deste trabalho foi escolhida uma empresa que
atua no mercado desde 2006. Os serviços desenvolvidos pela empresa são
projetos e execução de pavimentação, passeios e reformas em escolas e praças.
Por ser uma empresa criada há pouco mais de um ano, ela vem passando por
uma série de adequações e melhorias contínuas em seus processos, ainda não
tendo atingido um modelo considerado como “ideal”.
Assim surgiu a oportunidade de aplicar a UML em um dos processos

da empresa, visando à identificação de pontos críticos e propondo melhorias
de performance/qualidade, modelando o processo escolhido através do
Diagrama de Atividades. O processo escolhido para análise neste trabalho foi
a execução de pavimentos. Apresenta-se abaixo a descrição do procedimento
para que seja dado início a este processo.
131
O diagrama correspondente é mostrado na figura adiante.
Primeiramente deve haver interesse por parte dos moradores da rua

a ser beneficiada, visto que eles participam financeiramente da obra. Um
destes moradores deve ir até à empresa e retirar o “termo de adesão” para
colher as assinaturas dos vizinhos. Havendo interesse de, pelo menos, 70%
dos moradores da referida rua, é aberto um protocolo de pavimentação. No
Diagrama de Atividades mostrado na figura a seguir o processo inicia-se com
a abertura deste protocolo (1).
Um protocolo também é aberto para solicitações de vereadores, sendo

que neste caso não é exigido o termo de adesão, apenas o pedido é enviado ao
diretor-presidente, para que seja analisado (2).
Este protocolo, seja pedido de clientes ou de vereadores, é enviado ao

Departamento Comercial, para análise do referido trecho (3), e posteriormente
repassado à Engenharia, para que verifique se o trecho em questão já não foi
orçado anteriormente (4).
Assim, tem-se duas possibilidades: se o trecho já foi orçado este é

enviado diretamente ao arquivo (5), e o processo é finalizado; caso o trecho não
tenha sido orçado, o protocolo é enviado à Topografia para que seja realizado
o levantamento e feito o anteprojeto da rua (6).
Isto feito, o protocolo retorna à Engenharia para que sejam feitos o

orçamento e o projeto definitivo do trecho (7). Juntamente com o projeto e o
orçamento, o protocolo é enviado ao Departamento Comercial para que seja
feito o croqui com os dados da rua e dos respectivos moradores (8).
A partir deste momento, o mesmo departamento entra em contato com

o vendedor da região em questão, para repassar-lhe a pasta da rua, com o
croqui e o valor a ser pago pelos clientes para viabilização da obra (9). De posse
disto, o vendedor deve visitar cada morador, e oferecer-lhe a pavimentação
(10). Após as visitas, tem-se novamente duas situações: a rua pode ter atingido
70% de adesão, que é a exigência mínima para que seja executado o trecho, ou
não. Caso ocorra a última opção, o processo é arquivado (11). Se a rua atingir
os 70% de adesão, o vendedor solicita a documentação de cada morador e
preenche a ficha cadastral (12).
De posse de todos os documentos, o vendedor envia estes dados ao

Departamento Comercial para analisar toda a documentação da rua (13). Após
esta análise, a documentação pode estar completa (14), ou os clientes podem
ter impossibilidade de apresentar algum tipo de documento exigido, como
comprovante de renda, por exemplo. Neste caso, o protocolo é enviado ao
diretor-presidente para que ele avalie a documentação pendente (15).
132
Após a análise, a documentação pode ser reprovada (16), sendo o

processo arquivado, ou aprovada (17). Se a documentação for aprovada, ou
se ela já estivesse completa desde o início, o Departamento Comercial redige
os contratos (18). Pode-se ter dois tipos de contratos, quando o cliente financia
diretamente com a empresa (em até 30 vezes) (19), ou quando o financiamento
é feito pelo Banco do Brasil (em até 48 vezes) (20).
Os clientes que optarem por financiar com o Banco do Brasil recebem

um desconto de 15%, pois para a empresa o recebimento é à vista. Como o
Departamento de Engenharia só insere o trecho no cronograma de obras
quando a rua atinge 50% de recebimento, o trecho vendido é repassado ao
Departamento Financeiro, para aguardar esta porcentagem de recebimento
(21). Quando o financiamento acontece direto com a empresa, existe a consulta
ao SPC (22). Após a consulta tem-se novamente duas situações: o cliente pode
estar com a documentação regular ou pendente. Se a situação estiver regular
(23), o processo é encaminhado à Recepção, para que sejam impressos os
boletos (24).
Caso o cliente esteja com pendência no SPC, o Departamento Comercial

entra em contato com o vendedor (25), que avisa o cliente sobre a pendência no
SPC e verifica a possibilidade de regularizar a situação. Estes clientes podem
regularizar a situação, dando andamento ao processo e gerando os boletos
(26), ou não, continuando com a situação irregular (27). Neste caso, cabe à
presidência verificar se, retirando este cliente inadimplente, a rua continua
com 70% de adesão. Caso afirmativo, o processo segue, sendo repassado à
Recepção para que sejam impressos os boletos (28).
Se retirarmos este cliente, e a rua ficar com adesão inferior a 70%, este
protocolo é arquivado por falta de adesão (29). Com os boletos gerados, e os
clientes efetuando os pagamentos mensais, a rua é repassada ao Departamento
Financeiro (30) para que este realize o controle de recebimentos (21). Tão logo
a rua atinja os 50% de recebimento (31), esta é enviada ao Departamento de
Engenharia para que seja inserida no cronograma de obras (32). Para facilitar o
deslocamento dos maquinários, o cronograma de obras é dividido por regiões
da cidade, chamadas lotes.
Quando é iniciado um determinado lote, todas as ruas vendidas

desta região que estejam 50% pagas são pavimentadas. Buscando aumentar
a produtividade, pode-se executar a obra (33) ou terceirizar a obra (34).
No último caso, a empresa passa de executora a fiscalizadora, porém, o
procedimento é realizado da mesma forma. Quando a obra é finalizada, o
protocolo é arquivado (35).
133
RECEPÇÃO COMERCIAL ENGENHARIA TOPOGRAFIA VENDAS PRESIDÊNCIA FINANCEIRO ARQUIVO
(1)
Abrir
Protocolo
Solicitação de Vereadores (2)

Analisar
pedido
Solic.
de (1)
Cliente
(3)
(4)
Analisar Verificar os
o trecho trechos já
usados
Trecho já orçado (5) Protocolo

arquivado
Trecho
não
(6)
orçado
Relizar
Encaminhar levanta-
para mento e
levantamento anteprojeto
topográfico
Fazer croqui
com dados
da rua e (7)
Orçar e
respectivos (8) projetar o
moradores trecho
(9)
Conectar Visitar
vendedor da moradores
região (10)
não atingiu de adesão Protocolo

70% (11) arquivado
Rua c/
no mín.
70% de
adesão
Solicitar
a doc. de
cada
morador
(12)
(13) Preencher
Analisar a
a ficha
documentação
cadastral
apresentar um documento Analisar a

(15) documentação
Impossibilidade pendente
de
Doc.
Protocolo
arquivado
134
Ok
reprovada
(14) Doc. (16)
Doc.
(18) Cont. Apro- (17)

vada
(18) Cont.
Redigir contratos
(19) (20)
Financ. Financ.
c/ a c/BB
Empresa
(22)
Empresa
Consulta recebe
SPC a vista (21)
Avisar
cliente
sobre
pendência
Presidente no SPC
(25)
Verificar a
possibilidade de
regularizar a
situação
Regular
(23) Verificar se
(27) retirando este
Sit. cliente a rua
continua com
irreg. 70% de adesão
Sit.
Reg.
(26)
Protocolo
Não (29) arquivado
(24) Sim (28)
Fazer
boletos
(30)
(2
Aguardar
50% de
recebimento
(32)
(3 Rua atingida
Inserir o 50% de
trecho no recebimento
cronograma
de obras
Executar
a obra
135
(33)(34)
Terceirizar
a obra (35)
Protocolo
arquivado
Figura 1 - Diagrama de Atividades
2.1.7 Avaliação da Aplicação do Diagrama de Atividades

Após o mapeamento verificou-se que o Diagrama de Atividades da
UML permitiu a visualização do processo, possibilitando uma representação
padronizada das informações com um nível de detalhamento adequado. A
aplicação do Diagrama de Atividades no processo leva a organização a reconhecer
os pontos fracos ou gargalos da empresa. Neste estudo de caso, após o mapeamento
do processo, foram intensificadas as seguintes possibilidades de melhorias:
• Após ser aberto um protocolo, o Departamento Comercial o envia à

Engenharia, para que seja verificado se este trecho de rua já foi orçado ou
não (4), sendo que isto poderia ser feito pelos funcionários da recepção
antes mesmo de um protocolo ser aberto. Muitas vezes são abertos vários
protocolos para um mesmo trecho de rua, e isto só é verificado quando o
processo passa pelo Departamento de Engenharia.
• Se a Recepção procedesse conforme descrito acima, esta poderia repassar
o protocolo diretamente à Topografia, eliminando diversas etapas e
diminuindo o prazo entre a solicitação de clientes interessados e a visita de
um vendedor, já com o orçamento da rua.
• Quando o cliente financia direto com a empresa (22), é feita a consulta ao
SPC e, em diversos casos, os clientes estão com a situação pendente (25). Esta
consulta poderia ser efetuada diretamente pelo vendedor, antes de repassar
a documentação e as fichas cadastrais ao Departamento Comercial (13).
• Após a obra concluída é importante que um representante da empresa
retorne ao local para obter o feedback do serviço executado e também para
verificar se a obra está em perfeitas condições de uso e limpeza. É necessário
que se visite cada morador para que se possa obter um indicador de clientes
satisfeitos/insatisfeitos e propor uma meta a ser alcançada, preocupando-se
sempre em atingir resultados melhores. A principal vantagem da utilização
de um diagrama associado a UML é que após a análise e identificação de
possíveis melhorias em um processo, o modelo poderá ser aproveitado
integralmente para iniciar o desenvolvimento do sistema de informações
que dará suporte ao processo.
136
2.1.8 Conclusões
Observou-se que o mapeamento do processo através do Diagrama
de Atividades trouxe resultados importantes, como o entendimento e a
visualização global do processo por toda a organização, apresentando
as informações de forma clara e padronizada e mostrando o fluxo de uma
atividade para outra.
O Diagrama de Atividades também possibilitou encontrar os pontos

críticos e gargalos da empresa, e assim, propor sugestões de melhorias, que
certamente levarão a um aumento da eficiência e da qualidade do processo
como um todo, possibilitando o aumento de sua competitividade no mercado.
Conclui-se, tendo como base este estudo de caso, que o Diagrama de Atividades
da UML atendeu ao objetivo deste trabalho, permitindo o mapeamento de um
processo de negócio de maneira satisfatória, contribuindo para uma melhor
compreensão das atividades da empresa e suas interações, podendo ser utilizado
para modelagem de processos e não apenas para modelagem de softwares.

pdf>. Acesso em: nov. 2015.
137
O uso de software de apoio à modelagem é muito importante, por dois

motivos: primeiro porque os modelos começarão a ficar tão longos que a folha
de papel ficará pequena, segundo porque é uma ótima maneira de checar as
associações entre os modelos. [5]. O principal objetivo da tecnologia CASE é
separar o projeto da implementação do código. Existem várias ferramentas de
modelagem, algumas suportando a UML, porém muitas apoiam um método
particular que em si atende a um tipo de projeto. É essencial avaliar os benefícios
das ferramentas e suas limitações, evitando problemas posteriores no processo de
desenvolvimento.
Com um grande número existente de ferramentas CASE, com vários

recursos característicos que proporcionam, é necessário conhecer quais delas
apoiam melhor a UML. Entretanto, para que isto seja possível é preciso
fazer uma verificação das ferramentas disponíveis e avaliar suas principais
características.
Atualmente existem várias ferramentas de apoio à UML. O site Objects by

Design [7] apresenta, aproximadamente, 115 ferramentas com informações sobre
seus fabricantes, versões, datas, plataformas e preços (nem sempre disponível). O
138
presente artigo apresenta um modelo para avaliação de ferramentas de suporte
à UML, baseado em requisitos funcionais, não funcionais, bem como em normas
de qualidade. Inicialmente apresenta-se as categorias definidas no modelo de
avaliação, bem como os critérios que formam cada categoria. Apresenta-se a
seguir o estudo de caso que foi definido e realizado a fim de validar o modelo
proposto. Posteriormente, são apresentados os principais resultados obtidos com
o estudo de caso, algumas observações complementares constatadas na avaliação
e, finalmente, a conclusão.
2. O Modelo Proposto
O site anteriormente mencionado apresenta, também, uma lista comentada

de itens que devem ser considerados nas ferramentas. Porém, a lista não aponta
quais tipos de respostas devem ser buscados e nem uma organização precisa dos
itens (classificação), o que dificulta, em parte, sua aplicação. Além disso, os itens
não são relacionados com normas de qualidade. Sendo assim, a finalidade do
modelo proposto é estabelecer um conjunto de critérios, baseados em normas de
qualidade e classificados em requisitos funcionais e não funcionais, que permitam
a avaliação de ferramentas de apoio à UML.
Após a avaliação, segundo os critérios propostos, as informações obtidas

poderão auxiliar o futuro usuário na escolha da ferramenta de apoio à UML
mais adequada às suas necessidades. Os critérios definidos no modelo permitem
especificar como as ferramentas trabalham, se realmente executam o que seu
fabricante anuncia e se atendem aos requisitos dos usuários com qualidade.
Porém, não é objetivo do modelo indicar qual ferramenta é a melhor. A opção
será feita pelo usuário a partir dos resultados obtidos.
Para uma melhor definição dos critérios, investigou-se algumas normas

de qualidade existentes. As normas de qualidade investigadas foram: ISO/IEC
9126 - Engenharia de Software - Qualidade de produto de software, ISO/IEC 14598
- Tecnologia de informação – Guias para avaliação de produto de software, NBR
ISO/IEC 12119 - Tecnologia de informação - Pacotes de software - Testes e requisitos
de qualidade [4] e ISO/IEC 14102 - Tecnologia de informação – Orientação para
avaliação e seleção de ferramentas CASE. A lista de critérios para avaliação das
ferramentas foi criada para direcionar a avaliação. Os 57 critérios foram divididos
em funcionais e não funcionais e apresentam duas formas de resposta, como
mostra a Tabela 1.
Para uma melhor organização dos critérios, os mesmos foram classificados

em categorias que servem para agrupar os critérios que possuem características
semelhantes. Apresenta-se, a seguir, as oito categorias de critérios que foram
criadas, bem como os objetivos principais de cada uma delas:
• Baseados na norma ISO/IEC 9126: verificar nas ferramentas a existência de

características relacionadas a esta norma.
139
• Baseados em características de hardware e software: verificar em quais plataformas
de hardware e software as ferramentas podem ser utilizadas.
• Baseados no repositório de dados: verificar quais são as funções do repositório
nas ferramentas.
• Baseados na documentação: verificar que tipos de documentação acompanham
as ferramentas e se as mesmas auxiliam os desenvolvedores no uso das
ferramentas.
• Baseados no uso da ferramenta com relação ao computador utilizado: verificar
qual o desempenho das ferramentas com relação ao computador utilizado para
avaliação.
• Baseados na UML: verificar quais funções executadas pelas ferramentas
correspondem com as características da UML.
• Baseados no fornecedor: possibilitar informações detalhadas sobre o fornecedor,
produtos e suporte aos mesmos.
• Baseados nas necessidades identificadas com a utilização das ferramentas:
verificar se as ferramentas atendem às necessidades dos usuários.
Tabela 1 - Tipos de Resposta
Critério Tipo de resposta Código

É possível gerar código fonte Sim/Não/Em parte,
1
a a partir da modelagem? justificando se necessário.
Quais os bancos de dados
Resposta descritiva 2
apoiados pela ferramenta?
Nas próximas seções serão apresentados os critérios de cada categoria,

bem como a motivação da criação de cada uma das categorias. Nas tabelas, a
coluna “Resp” refere-se ao tipo de resposta do critério, conforme Tabela 1, e a
coluna “Req” (Requisito) corresponde a F (Funcional) ou NF (Não Funcional).
2.1 Critérios baseados na norma ISO/IEC 9126
Os critérios desta categoria foram criados com base na norma ISO/IEC 9126.
O objetivo é descobrir como as ferramentas atendem algumas características desta
norma. Foram consideradas as características manutenibilidade (subcaracterísticas
modificabilidade e analisabilidade), confiabilidade (subcaracterística maturidade),
funcionalidade (subcaracterística interoperabilidade) e apreensibilidade. Nesta
categoria foram criados 22 critérios, sendo que a Tabela 2 apresenta alguns
exemplos.
140
Tabela 2 - Critérios baseados na norma ISO/IEC 9126
Critério Objetivo Resp Req

Avalia a possibilidade de manipulação dos
É possível incluir, excluir, objetos na ferramenta depois de criados.
mover, agrupar, desagrupar O objetivo é verificar se após os elementos 1 F
e redimensionar objetos? serem criados, os mesmos podem ser
modificados.
Verificar se a ferramenta auxilia o
Possui opções para análise
desenvolvedor na depuração da modelagem, 1 F
dos diagramas?
analisando todos os elementos criados.
É possível gerar código, Verificar se o usuário poderá gerar
fonte a partir da código para a aplicação que está sendo 1 F
modelagem criada? desenvolvida.
É possível fazer engenharia
Verificar se a ferramenta possui este recurso. 1 F
reversa de dados?
É possível importar e Verificar quais ferramentas importam/exportam
1 NF
exportar dados? arquivos do projeto que está sendo criado.
Na ferramenta é possível
Avaliar se é possível utilizar subsídios de
valer-se de informações de 1 NF
outras ferramentas.
outras ferramentas?
Os arquivos criados na
Avaliar se os arqeuivos criados na ferramenta
ferramenta são portáveis
podem ser utilizados nas versões da 1 NF
para a mesma ferramenta
ferramenta criadas para outras platafromas.
em outra plataforma?
A ferramenta possui
Avaliar se a ferramenta possui alguma
restrição quanto ao número
restrição quanto a criação de elementos na 1 NF
de objetos criados pela
ferramenta.
mesma na modelagem?
Existe maneira de prevenir Verificar se a ferramenta possui recuperação
falhas originadas por de dados por meio de defeitos de hardware 1 NF
hardware ou software? e/ou software
A organização gráfica dos Avaliar se a ferramenta é fácil de ser
elementos visuais promove manipulada, verificando se o usuário terá
1 NF
a compreensão do usuário facilidade para utilização da ferramenta a
na utilização da ferramenta? partir da visualização dos elementos.
2.2 Critérios baseados na UML
Esta categoria é composta de quatro critérios que permitem avaliar

a relação da ferramenta com características especiais da UML, como
possibilidade de definição de herança múltipla, possibilidade de criação de
todos os diagramas propostos pela linguagem e possibilidade de armazenar
tarefas intermediárias dos casos de uso. A Tabela 3 apresenta os critérios
definidos para esta categoria.
141
Tabela 3 - Critérios baseados na UML

Permite definir tarefas
Verificar se é possível documentar tarefas
intermediárias em casos de 1 F
intermediárias dos casos de uso.
uso?
Permite definição de Verificar se a ferramenta possui esta opção no
1 F
herança múltipla? diagrama de classes.
Permite a criação de todos
Verificar se é possível criar todos os
os diagramas propostos 1 F
diagramas da UML.
pela UML?
Qual é a versão da UML Informar ao usuário qual é a versão da UML
2 NF
suportada pela ferramenta? suportada pela ferramenta.
2.3 Critérios baseados no fornecedor
Com os critérios desta categoria é possível obter-se informações mais

detalhadas sobre os fornecedores das ferramentas, como tempo de existência,
forma de comercialização dos produtos, suporte oferecido etc. Foram definidos 11
critérios e todos correspondem a requisitos não funcionais. A Tabela 4 apresenta
exemplos de critérios definidos para esta categoria.
Tabela 4 - Critérios baseados no fornecedor

Critério Objetivo Resp
Há quanto tempo o fornecedor Informar há quanto tempo o fornecedor está
2
está no mercado? atuando no mercado.
O fornecedor comercializa outros Verificar se existem outros produtos
2
produtos? desenvolvidos pelo fornecedor.
Há quanto tempo a ferramenta Verificar há quanto tempo a ferramenta está
2
está disponível? disponível para utilização.
Como é possível adquirir a Verificar quais são as possibilidades de aquisição
2
ferramenta? da ferramenta.
Como é feito o suporte aos Verificar como é realizado o atendimento ao
2
clientes? usuário
Verificar se a ferramenta possui alguma certificação
O produto possui alguma
de qualidade ou se existe alguma preocupação por 1
certificação de qualidade?
parte do fabricante quanto a isto.
142
2.4 Critérios baseados nas necessidades identificadas com a utilização da
ferramenta
A partir dos seis critérios definidos nesta categoria é possível verificar se

as ferramentas atendem às necessidades dos usuários na utilização das mesmas.
A Tabela 5 apresenta exemplos de critérios definidos para esta categoria.
Tabela 5 - Critérios baseados nas necessidades identificadas com a utilização da ferramenta

É possível gerar histórico Avaliar se disponibiliza registros do que é
1 F
das ações executadas? criado.
Avaliar se existe controle para determinadas
É possível abortar/desfazer
ações, verificando se é possível desfazer ou 1 F
ações executadas?
abortar ações facilitando a criação dos modelos.
Existe alguma forma de
Avaliar se existe controle e gerenciamento de
controle e gerencimaneto 1 F
usuários.
de usuários?
Quais são os conhecimentos Identificar e informar quais devem ser os
2 NF
mínimos para usar? conhecimentos básicos de utilização.
2.5 Critérios baseados em características de hardware e software
A partir dos critérios desta categoria é possível verificar as necessidades de

hardware e software das ferramentas. Foram definidos cinco critérios nesta categoria
e todos correspondem a requisitos não funcionais. Alguns exemplos são:
• É possível executar a ferramenta em quais sistemas operacionais? O objetivo

deste critério é identificar para quais sistemas operacionais as ferramentas estão
disponíveis. A resposta para este critério é descritiva (tipo 2), ou seja, uma lista
de sistemas operacionais.
• Quais são os requisitos mínimos aconselhados pelo fornecedor para a utilização
da ferramenta? Busca-se verificar quais os requisitos (memória, espaço em disco,
processador, etc.) mínimos para a utilização das ferramentas. A resposta informa
ao usuário qual deve ser a capacidade mínima do seu computador para que
ele possa utilizar a ferramenta satisfatoriamente. A resposta para este critério é
descritiva (tipo 2), ou seja, a configuração mínima sugerida pelo fabricante.
• É preciso uma base de dados específica para a ferramenta? Com este critério é
possível investigar se as ferramentas necessitam de alguma base de dados para
a criação dos diagramas. A resposta para este critério é do tipo 1.
2.6 Critérios baseados no repositório de dados
Nesta categoria buscou-se informações que permitissem avaliar as

funções dos repositórios de dados das ferramentas. Para atingir este objetivo
foram criados três critérios:
143
• Existe repositório? O objetivo deste critério é avaliar de que forma a ferramenta
armazena os dados.
• Através do repositório é possível criar informações (classes, atributos, ligações)?
Com este critério busca-se avaliar se os repositórios das ferramentas permitem
a criação dos elementos dos diagramas a partir das informações salvas.
• É possível recuperar os dados do repositório? Busca-se informações para avaliar
se os repositórios das ferramentas permitem a recuperação dos elementos
dos diagramas a partir das informações salvas. Os critérios desta categoria
correspondem a requisitos funcionais e possuem tipo de resposta 1.
2.7 Critérios baseados na documentação
Os critérios desta categoria demonstram a relação das ferramentas com

a respectiva documentação. O objetivo é verificar se existe uma preocupação
quanto à documentação e como a mesma é disponibilizada. Foram criados
quatro critérios nesta categoria, todos correspondem a requisitos não funcionais
e possuem resposta do tipo 1. A seguir são apresentados alguns exemplos de
critérios desta categoria:
• Existe help, manuais e documentação que auxilie o usuário a esclarecer

dúvidas? A partir da resposta a este critério é possível verificar a existência
de documentação, de que tipo é a mesma e se realmente auxilia o usuário na
utilização da ferramenta.
• Existe documentação que esclarece dúvidas quando à instalação? O objetivo
é verificar se existe alguma documentação que auxilie a instalação da
ferramenta.
• É possível configurar a forma como a documentação será gerada? Com este
critério é possível verificar se o usuário poderá alterar a documentação gerada
pela ferramenta de acordo com suas necessidades.
2.8 Critérios baseados na utilização da ferramenta com relação ao computador

utilizado para avaliação
Nesta categoria busca-se informações que permitam avaliar as ferramentas

com relação ao computador utilizado para avaliação das mesmas. Para atingir
este objetivo foram criados dois critérios:
• Possui tempo de resposta apropriado? A partir da resposta a este critério

pretende-se detectar como foi a resposta aos processos feitos na ferramenta.
• Qual o desempenho no computador utilizado? A intenção é indicar a viabilidade
da utilização, orientando o usuário se poderá utilizá-la com a tecnologia que
possui ou deverá utilizar mais recursos. Os critérios desta categoria correspondem
a requisitos não funcionais e possuem resposta descritiva (tipo 2).
144
3. Aplicação do modelo
A fim de validar o modelo proposto, foi definido e elaborado um estudo

de caso. Escolheu-se algumas ferramentas e elaborou-se os diagramas da UML
com base em um Controle de Simpósio. Inicialmente foram identificados os atores
e, logo após, realizou-se um levantamento das responsabilidades de cada um.
As responsabilidades foram descritas como pequenas tarefas. A análise destas
tarefas intermediárias possibilitou a identificação de prováveis casos de uso que
serviram de base para a construção do diagrama correspondente. Em seguida,
tornou-se possível a identificação das classes, bem como suas características e
relacionamentos, dando origem ao Diagrama de Classes.
A partir da descrição das tarefas intermediárias de cada diagrama de caso

de uso foram desenvolvidos os diagramas de sequência. A seguir, com base na
classe Participante, criou-se o Diagrama de Estados e o Diagrama de Atividades
baseou-se na classe Cancelamento. A Figura 1 apresenta uma parte do Diagrama
de Classes construído.
Todos os diagramas elaborados encontram-se em [2]. As ferramentas

escolhidas para este estudo foram a Rational Rose C++ Demo2 da IBM/Rational,
PowerDesigner 9.03 da Sybase, Together ControlCenter 6.14 da Borland,
AllFusion Component Modeler 4.15 da CA (Computer Associates), Enterprise
Architect 3.516 da Sparx Systems, Poseidon for UML Community Edition 1.67 e
ArgoUML 0.148. A Rational Rose foi escolhida por ser desenvolvida pela mesma
empresa da UML; a PowerDesigner 9.0 por ser uma ferramenta de modelagem
muito utilizada no meio acadêmico em geral; a Poseidon e a ArgoUml por serem
ferramentas de código aberto; a Together ControlCenter, a AllFusion Modeler
e a Enterprise Architect por serem ferramentas encontradas nas referências
utilizadas.
Além disso, foi possível encontrar cópias de demonstração de todas as

ferramentas acima citadas. A avaliação das ferramentas foi realizada através da
aplicação do estudo de caso nas mesmas e consulta a informações disponibilizadas
pelo seu fornecedor por meio da documentação de cada uma delas.
3.1 Resumo dos Resultados
Durante a avaliação foi possível criar a modelagem de acordo com

as exigências da UML. Constatou-se que cada ferramenta possui padrões e
características diferentes. Os principais resultados constatados com a avaliação
são mostrados na Tabela 6.
145
3.2 Observações finais sobre a avaliação
Através da avaliação verificou-se que cada ferramenta possui

características e padrões diferentes que devem ser ressaltados. Identificou-se que
em todas as ferramentas é possível criar a modelagem conforme a UML, porém,
dependendo da ferramenta isto pode ser feito com maior ou menor dificuldade.
Todas as ferramentas estudadas oferecem várias formas de documentar os
projetos, reforçando uma das principais características da UML, que é de ser
uma linguagem de documentação. Além dos diagramas da UML, constatou-
se que algumas ferramentas, como a Together ControlCenter, Enterprise
Architect e Allfusion Component Modeler, oferecem modelagem de negócios,
e a PowerDesigner possibilita modelagem física e conceitual. Observou-se,
com exceção da versão da Rational Rose estudada, que todas as ferramentas
preocupam-se com a portabilidade dos seus modelos, mesmo as que não possuem
versões para outros sistemas operacionais, pois elas oferecem exportação de seus
modelos em XML. A maioria das ferramentas é bem construída graficamente,
a Poseidon e a Together ControlCenter possuem ícones com os desenhos na
forma dos diagramas correspondentes, facilitando a compreensão e agilizando
a construção dos mesmos. Além disto, com exceção da AllFusion Component
Modeler, todos os diagramas podem ser visualizados facilmente através do
browser, pois são agrupados conforme o tipo de diagrama de acordo com a UML.
As empresas que não possuem recursos financeiros ou não desejam gastar para
adquirir uma ferramenta podem utilizar a Argouml e a Poseidon, porque são de
código aberto e distribuídas gratuitamente.
4. Conclusões
A UML é uma tendência entre desenvolvedores de aplicações baseadas

em modelos orientados a objetos, entretanto, há uma grande dificuldade de
encontrar experiências práticas e exemplos mais realistas na literatura, tornando
lento o processo de inserção desta metodologia no mercado de trabalho. Existem
grandes esforços para mudar este panorama. A prova disto é o investimento do
OMG em melhorias na UML lançando constantemente novas versões. Atualmente,
existem várias ferramentas de apoio à UML. A fim de facilitar a avaliação destas
ferramentas, definiu-se um modelo composto por um conjunto de critérios
baseados em requisitos funcionais, não funcionais e normas de qualidade. O
objetivo do modelo é auxiliar o usuário para que ele obtenha informações sobre
cada ferramenta a fim de que, a partir destas informações, possa escolher a
que melhor atenda às suas necessidades ou, valendo-se dos dados do estudo,
criar uma nova avaliação. Não é objetivo deste modelo indicar qual a melhor
ferramenta, bem como abordar custos de aquisição e manutenção. Sugere-se que
após a realização da avaliação, o usuário estabeleça prioridades aos critérios de
acordo com suas necessidades. Para os critérios podem ser atribuídas faixas de
valores, por exemplo 0 a 5, que demonstrará em que grau a ferramenta atende
àquele critério. Assim, a ferramenta que melhor atender as necessidades é a que
146
totalizar mais pontos. Cabe enfatizar que, na seleção de ferramentas, é importante
considerar tanto os requisitos funcionais como os não funcionais. Por esta razão,
na elaboração dos critérios do modelo proposto teve-se a preocupação em fazer
esta distinção.
O crescente aumento de novas ferramentas disponíveis, incluindo

algumas de código aberto e uso livre, e a constante atualização das mesmas para
versões superiores, motivam a complementação deste trabalho abrangendo mais
características das ferramentas avaliadas, com a elaboração de novos critérios.
Também é possível estender a avaliação realizada para um maior número de
ferramentas.
147
Cidade Cancelamento
codcid: string codpant: Participante
nomecid: string dtcancel: string
0...*
UF: string 1 0...*
Participante
(from Use Case View
Vagas ccodpart Categoria

nome: string 1
codvaga: integrar codcat: integer
endereco: string
qtdisp: integer descat: string
drinscircao: string
qtvaga: integer valor: float
dtpgto: string
Evento: string
Cep: string
Periodo: string
Fone: string
codcid: Cidade
status: string
codcat: Categoria
Profissional da Area Professor Estudante Outro

codemp: string area: string matricula: string Atividade: string
codcargo: string codinst: instituição nivel: string
Tabela 5 - Critérios baseados nas necessidades identificadas com a utilização da ferramenta
Item Resultado
Com exceção da Rational, todas exportam dados em XML, A
PowerDesigner importa os modelos criados na Rational, mas o
Importação e
diagrama de classes fica com os objetos e ligações confusos na
Exportação de Arquivos
ferramenta, após a importação. A Poseidon abre modelos criados na
Argouml e vice-versa.
A Enterprise Architect e Allfasion possuem versões apenas para o
WIndows, as demias (exceto a PowerDesigner que não identificou-se)
Portabilidade
contém versões para outros sistemas operacionais. A Poseidon e a
Argouml inpedem do mesmo.
128 MB de RAM recomendada pelo fornecedor é insuficiente para a
utilização da Poseidon e da Argouml. Para a Together é recomendado
no mínimo 512MB. As ferramentas Together e Allfusion requerem
grande espaço em disco (a partir de 100 MB); par Enterprise Architect
Harware e Software Argouml e Rational Rose é necessário até 15 MB e par Poseidon e
Necessários PowerDesigner não foi possível identificar, porém o tamanho do
arquivo de instalação das mesmas e superior a 60MB. O drive de
CD só é necessário para instalação das ferramentas. Recomenda-se
uma placa de vídeo com resolução mínima de 800x600, exceto para a
Together pois o fornecedor recomenda 1024x768.
148
Somente a Allfusion necessita de instalação de uma base de dados
específica (MS SQL Sever). A PoqerDesigner, Enterprise Architect e
AllFusion Component Modeler possuem repositórios de dados que
permitem controlar uusários ou grupos de usuários, atribuindo-
lhes permissões para os projetos; a Together também contém este
Reposi´torio de Dados
controle, porém como acontece com as demais, o repositório de
dados é utilizado apenas como um browser para visualização dos
elementos dos diagramas. Com exceção da Poseidon e da Rational
Rose (que não foi possível identificar), todas têm suporte a algum
banco de dados.
Com exceção da AllFusion Component Modeler, todas são muito

Interface
bem organizadas graficamente.
Todas são acompanhadas de documentação, sendo também

Documentação
disponibilizadas na página correspondente.
COm execção da AllFusion Component Modeler, não houve

Conhecimentos Prévios
dificuldades na manipulação das ferramentas.

pdf>. Acesso em: 10 nov. 2015.
149
RESUMO DO TÓPICO 3
Neste tópico você:
• Observou que o mapeamento do processo através do Diagrama de Atividades

trouxe resultados importantes, como o entendimento e a visualização global do
processo por toda a organização, apresentando as informações de forma clara e
padronizada e mostrando o fluxo de uma atividade para outra.
• O Diagrama de Atividades também possibilitou encontrar os pontos críticos e

gargalos da empresa e, assim, propor sugestões de melhorias, que certamente
levarão a um aumento da eficiência e da qualidade do processo como um todo,
possibilitando o aumento de sua competitividade no mercado.
150
AUTOATIVIDADE
1 Descreva os passos do Diagrama de Atividades proposto no Estudo de Caso

abordado acima.
151
152
REFERÊNCIAS
ANDRADE, C. A. V. Metodologia de Análise de Sistemas. 8. Módulo. ESAB –
Escola Superior Aberta do Brasil: Vila Velha, 2007.
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de

Janeiro: Elsevier, 2007.
BIGERSTAFF, T; RICHTER C. Re-usability Framework, Assessment and

Directions. Tutorial: Software Reuse - Emerging Technology. IEEE Computer
Society, EH0278-2, p. 3-11. 1989.
BLAHA, M.; RUMBAUGH, J. Modelagem e projetos baseados em objetos com

UML 2. 2. ed. Rio de Janeiro: Elsevier, 2006.
BOOCH, G. Object-Oriented Analysis and Design with Applications. USA:

Redwood City, Benjamin, 2006.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário.

Rio de Janeiro: Elsevier, 2005.
BROOKS, F. P. No Silver Bullet: Essence and Accidents of Software

Engineering. Computer, New York, vol. 20, n.4, p. 10-19, Apr. 1987.
FRANK, A U., EGENHOFER, M. J. Computer Cartography For GIS: An Object-

Oriented View On The Display Transformation. Computers & Geosciences,
Oxford, v. 18, n. 8, p. 975-987, 1992.
GRAHAM, I. Object Oriented Methods. Addison-Wesley: Wokingham,

England, 1994.
GUEDES, G. T. A. Uml 2: Uma Abordagem Prática. 2. ed. São Paulo: Novatec,

2011.
______. Uml 2: Guia Prático. São Paulo: Novatec, 2007.
HAMILTON, K.; MILES, R. Learning UML 2.0. O’Reilly, 2006.
HERRING, J. A Data Model For An Object-Oriented Geographic Information

System. Computers
& Geosciences, Oxford, v. 18, n. 4, p. 443-452, 1992.
LARMAN, C. Utilizando UML e padrões. 3. ed. Porto Alegre: Bookman, 2007.
153
MANHANI, D. M. da S.; SCHIMIGUEL, J. Ferramentas case para modelagem
de banco de dados. Codificando .net e-magazine. Rio de Janeiro, ano 4, v. 14, 1º
fev. 2010.
MARTINS, D. M. S. et al. Projeto de software com astah*. Engenharia de

software magazine. Rio de Janeiro, ano 3, v. 30, 11 mar. 2010.
MELO, A. C. Desenvolvendo Aplicações com UML 2.2. 3. ed. Rio de Janeiro:

Brasport, 2011.
PIVA, G. D. Análise e Gerenciamento de Dados. Manual de Informática

Centro Paula Souza, v. 3, São Paulo, 2010.
PRIETO R.; FREEMAN, P. Classifying software for reusability. IEEE Software,

[S. l.], v. l4, n.1, p. 6-16, 1987.
RUMABAUGH, J. E. et al. Object-Oriented Modeling and Design. Englewood

Cliffs, New Jersey: Prentice Hall, 1991.
SILVA, R. P. e. UML 2 em Modelagem Orientada a Objetos. Florianópolis:

Visual Books, 2007.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Addison Wesley,

2011.
SOMMERVILLE, I. Software Engineering. Wokingham, England: Addison-

Wesley, 1989.
TACLA, C. A. ANÁLISE E PROJETO OO E UML 2.0. Apostila: Departamento

Acadêmico de Informática. Universidade Federal Tecnológica do Paraná, 2010.
TONSIG, S. L. Engenharia de software: Análise e Projeto de Sistemas. 2. ed. Rio

de Janeiro: Ciência Moderna, 2008.
VIDEIRA, C. A. E. UML, metodologias e ferramentas case. 2. ed. Lisboa: Centro

Atlântico, 2008.
ZHANG, H. BJORNERUD, M. A Macintosh Application Program for Simulating

Shear-Sense Indicators Using Object-Oriented Programming. Computers &
Geosciences, Oxford, v. 21, n. 3, p. 365-375, 1995.
154
ANOTAÇÕES
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
155
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
156

Análise Orientada A Objetos II

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Análise Orientada A Objetos II

Diunggah oleh

Hak Cipta:

Format Tersedia

Análise Orientada a

Revisão, Diagramação e Produção:

Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

1. Programação Orientada a Objetos.

Neste universo você vai se deparar com termos como atributos,

Este caderno pressupõe que você já possua alguma experiência

Aproveito a oportunidade para destacar a importância de desenvolver

Vale destacar a necessidade de dedicação e de muita determinação,

Lembre-se de que o mundo da informática é encantador, assim, seu

Bom estudo! Sucesso na sua trajetória acadêmica e profissional!

Simone Cristina Aléssio

Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto

Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é

Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente,

Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de

TÓPICO 1 – REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE

TÓPICO 2 – MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, DIAGRAMA

TÓPICO 3 – DIAGRAMA DE ATIVIDADES E DIAGRAMA DE

UNIDADE 2 – DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)....................................... 65

TÓPICO 1 – DIAGRAMAS DE INTERAÇÃO................................................................................... 67

TÓPICO 2 – DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES

TÓPICO 3 – DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE COMPONENTES............... 97

UNIDADE 3 – DIAGRAMAS ESTRUTURAIS................................................................................ 109

TÓPICO 1 – DIAGRAMA DE IMPLANTAÇÃO E ESTRUTURA COMPOSTA....................... 111

TÓPICO 2 – INTEGRAÇÃO DOS DIAGRAMAS – UMA VISÃO GERAL DO

TÓPICO 3 – ESTUDO DE CASO........................................................................................................ 125

• revisar conceitos de Orientação a Objetos;

• revisar conceitos de UML;

• conhecer a visão comportamental dos diagramas da UML;

• elaborar diagramas de casos de uso, de atividades e máquina de estados.

TÓPICO 1 – REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS,

TÓPICO 2 – MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML,

TÓPICO 3 – DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA

REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS,

FIGURA 1 – ORIGEM E EVOLUÇÃO DA UML

1963 - Ivan Sutherland desenvolve,

1969 1970 - 1983

1985 - 1989 1990 - 1993

FONTE: Piva (2010)

Este tópico foi criado com o objetivo de revisar conceitos da disciplina

Três grandes nomes criaram a UML. Dois deles são norte-americanos:

Método de Booch: desenvolvido por Grady Booch, da Rational Software

OOSE (Object-Oriented Software Engineering), de Ivar Jacobson, que

OMT (Object Modeling Technique), de James Rumbaugh, que é um método

FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>. Acesso em: 5 out. 2015.

À época do surgimento da linguagem Smalltalk, Kay era pesquisador da

A UML oferece suporte em todas as etapas do desenvolvimento de software.

O conceito continua evoluindo, pois ainda existem limitações de hardware

A abstração foca o escopo da entidade. Por exemplo, ao pensarmos na

FIGURA 2 – REPRESENTAÇÃO DE UMA CLASSE

FONTE: Piva (2010)

FIGURA 3 – OUTRA FORMA DE REPRESENTAÇÃO DE CLASSE

FONTE: Piva (2010)

Atributo: Pode ser entendido como um campo, uma propriedade que

• Construtor: é o método que constrói, isto é, reserva o espaço em memória onde

Os métodos Get e Set encapsulam os atributos de uma classe, garantindo

Get (para retornar o valor que está no atributo).

Normalmente, no processo de desenvolvimento são adotados um método

• Destrutor: destrói o objeto criado da memória, liberando o espaço de memória

2.2.3 Tipos de relacionamento entre classes

1) Dependência: determina que um objeto de uma classe possa usar as informações

FIGURA 4 – DEPENDÊNCIA DA UML

FONTE: Piva (2010)