Conteúdo teórico sobre Diagramas estruturais.

1. UNIVERSIDADE FEDERAL DE OURO PRETO
INSTITUTO DE CIÊNCIAS EXATAS E APLICADAS
DEPARTAMENTO DE CIÊNCIAS EXATAS E APLICADAS
ENGENHARIA DE SOFTWARE II
UML ,
Diagramas estruturais
Jéssica Pires – 09.1.8068, Priscila de Ávila - 09.1.8050, Rafaela Priscila - 09.1.8080, Thaise Delfino - 09.2.8115

2. Sumário
Introdução ................................................................................................................................ 2
História do UML ........................................................................................................................ 3
Diagramas Estruturais ............................................................................................................... 4
Diagrama de Classes ................................................................................................................. 5
Diagrama de objetos ................................................................................................................. 8
Diagramas de Pacotes ............................................................................................................. 11
Diagrama de Estrutura Composta............................................................................................ 12
Diagrama de Componentes ..................................................................................................... 13
Diagramas de Implantação ...................................................................................................... 16
Diferenças entre os Diagramas ................................................................................................ 17
Aplicação ................................................................................................................................ 18
Conclusões.............................................................................................................................. 19
Referências Bibliográficas ....................................................................................................... 20
1

3. Introdução
Modelagem nada mais é do que uma representação do software a ser feito sobre
imagens e aspectos que facilite o usuário a enxergar o que deve ser feito em seu trabalho.
Geralmente são feito diagramas e existem inúmeras ferramentas no mercado para ajudar a
elaborar esses diagramas. A UML (Unified Modeling Language) é uma linguagem para fazer
exatamente isso: modelagem de software.
A UML é uma linguagem na qual se obtém a especificação desejada, a documentação
correta e uma fácil visualização do projeto para um sistema orientado a objetos. Através de
seus diversos diagramas podemos obter diferentes perspectivas de visualização. Facilita na
comunicação entre as pessoas envolvidas com o sistema, como gerentes, coordenadores,
analistas e desenvolvedores, pois apresenta uma forma fácil de entender o problema como um
todo.
2

4. História do UML
No início da utilização de programas orientados à objetos, vários foram os métodos de
modelagem que surgiram, porém apenas três deles se destacaram por não estender os
métodos estruturados já existentes, erro cometido pelos demais. Cada método possuía pontos
fontes e diferentes entre si, um deles era focado em casos de uso (OOSE de Ivar Jacobson),
outro focava na fase de projeto (Booch’93 de Grady Booch) e o terceiro era voltado para
análise de sistemas de informação (OMT-2 de James Rumbaugh).
Em outubro de 1994 começaram os projetos para a junção destes três métodos. Em
1995, dois deles já eram unificados (Booch’93 e o OMT-2), um tempo depois, OOSE passou a
fazer parte desse conjunto, formando assim o “método unificado”.
Em julho de 1996, os três criadores do “método unificado” lançaram uma versão desse
novo método com a união dos outros três já existentes. A versão foi batizada de UML e mais
tarde lançaram várias outras novas versões.
A OMG3 (organização internacional que aprova padrões abertos para aplicações
orientadas a objetos) contribuiu imensamente para o crescimento da UML, pois ela lançou
uma solicitação de proposta para que outras empresas também pudessem contribuir com o
crescimento do UML, depois disso ela chegou a sua versão 1.1 e a OMG3 passou a se
responsabilizar pelas revisões e a adotou como linguagem padrão. As revisões são feitas com o
cuidado de não modificar a ideia principal do projeto e isso acaba sendo um motivo para
disseminar a linguagem para o mundo inteiro.
A linguagem UML chegou a sua versão 2 em 2003. Essa versão é composta por treze
diagramas, esses diagramas são divididos em diagramas de comportamento e diagramas
estruturais, da qual iremos tratar no restante do nosso trabalho.
3

5. Diagramas Estruturais
Os diagramas estruturais são aspectos estáticos, ou seja, representação da estrutura
de um sistema. Eles são classificados em diagramas de classe, objetos, de pacotes, de estrutura
composta, de componentes e de implementação.
DIAGRAMAS
ESTRUTURAIS
DIAGRAMA DE
DIAGRAMA DE DIAGRAMA DE DIAGRAMA DE DIAGRAMA DE DIAGRAMA DE
ESTRUTURA
CLASSES OBJETOS PACOTES COMPONENTES IMPLEMENTAÇÃO
COMPOSTA
4

6. Diagrama de Classes
O diagrama de classes é o diagrama principal do modelo estrutural, ele é o diagrama
que chega mais perto do código do programa, onde é fácil visualizar as classes, seus métodos,
atributos e os relacionamentos, de acordo com a especificação do sistema podemos fazer uma
modelagem utilizando esses dados.
Precisamos, antes de tudo, saber o que é uma linguagem com orientação a objetos.
Basicamente é abstração de conceitos do mundo real. Para compreendermos melhor,
podemos citar o exemplo de uma locadora de filmes, temos que pensar em dividir esse
problema em objetos. Neste exemplo temos os seguintes objetos: CD’s e Fitas, Clientes, etc. A
melhor forma de conceituar é imaginar objetos do mundo real e tentar abstrair esses
conceitos.
Um exemplo real:
Meu cachorro Thor. Posso descrever seus atributos físicos: é grande, sua cor principal
é castanha, olhos pretos, orelhas grandes e caídas, rabo grande. Além de seus atributos físicos,
posso descrever algumas ações que ele costuma fazer: balança o rabo quando chego em casa,
late quando ouve um barulho estranho, trás a bola pra mim quando quer brincar. Temos baixo
a representação do Thor.
Temos então a representação de um objeto (Thor) que possui determinadas
propriedades e métodos:
Propriedades: Cor do corpo: castanha, Cor dos olhos: preto, Altura: 30 cm
Comprimento: 80 cm, Largura: 24 cm.
Métodos: Balançar o rabo, Brincar, Latir, Deitar.
Para tratar objetos, temos as classes. Então temos uma classe: Cachorro, onde eu
posso representar o Thor. Podemos pensar em classe como um modelo para criar várias outros
objetos. Funciona como um carimbo, temos o carimbo e com ele podemos fazer quantas
cópias do mesmo modelo quisermos.
A representação gráfica de uma classe é feita em um triangulo com três divisões: nome
da classe, atributos e métodos.
5

7. Atributos: Um atributo especifica características gerais para um objeto. Mas cada
objeto pode receber valores diferentes em cada atributo. Então, no exemplo do cachorro Thor,
temos que os atributos dele são aqueles descrito acima, mas podemos criar um outro objeto
cachorro com outras propriedades, ou seja, outros atributos. Podemos representar a
visibilidade dos atributos utilizando as seguintes marcações:
 + público - visível em qualquer classe
 # protegido - qualquer descendente pode usar
 - privado - visível somente dentro da classe
Métodos: são ações que representam um determinado objeto. Como no exemplo
anterior, temos que o meu cachorro, Thor, pode latir, sentar, comer, etc.
Os objetos possuem relações entre si, uma classe pode se relacionar com outra. O
UML reconhece três importantes tipos de relação: dependência, associação e generalização
(ou herança). As relações são esquematizadas da seguinte forma.
Associação: São relacionamentos entre instâncias, indica que objetos de duas classes
diferentes podem estar relacionados. Por exemplo, uma classe professor e uma classe
disciplina, onde uma instância da classe professor terá uma associação com uma instância da
classe disciplina.
Dependência: Relacionamentos em que um elemento de uma classe depende de um
elemento de outra classe, logo, se houver alteração em um elemento o outro também se
alterará.
Generalização: Relacionamento entre elementos generalistas e especialistas, na qual a
classe especialista herda da outra propriedades e métodos gerais.
Agregação Regular: É a associação onde o objeto parte é um atributo do todo. Os
objetos parte são criados apenas quando o todo ao qual está agregado também é criado. Um
exemplo prático seria uma classe Pedido e uma classe Item. O pedido só pode ser feito quando
os itens do pedido estão disponíveis.
6

8. Composição – Relacionamento onde existe um elemento como o todo e um como a
parte do todo. A parte do todo só pertence ao todo e são criadas e destruídas nele.
O diagrama de classes é consequência de um levantamento de requisitos feitos
previamente. Como exemplo podemos fazer o levantamento de requisitos para um sistema de
consultório dentário. As etapas são:
 Levantamento e análise de requisitos do sistema a ser desenvolvido. Entrevista com o
cliente, no caso o proprietário de uma clinica, um dentista, ou mesmo funcionários
que saibam dar as informações de maneira clara e especifica.
 Definição dos objetos do sistema: Paciente, agenda, dentista, serviço, contrato,
consulta, pagamento, etc..
 Definição e detalhamento das ações: marcar consulta confirmar consulta cadastrar
paciente, cadastrar serviços, etc.
 Definição das classes: paciente, dentista, exame, agenda, serviço.
 Definir os atributos e métodos das classes.
Após toda esta análise, podemos construir o diagrama que represente esse problema.
Neste exemplo, temos as classes paciente, Agenda, serviço, consulta, horário,
limpeza/Restauração e Exame. Cada classe possui seus atributos e métodos e cada uma possui
uma relação com outras classes.
7

9. Diagrama de objetos
O Diagrama de Objetos é uma variação do Diagrama de Classes, e é muito pouco
utilizado. Eles são usados, também, como parte dos diagramas de comunicação, onde os
objetos do sistema possuem um vínculo. Nessa variação do diagrama, podem ser atribuídos
nomes reais aos objetos. Os diagramas de Objetos não são tão importantes como os
diagramas de classes, mas são muito úteis para simplificar diagramas de classes mais
complexos e de difícil entendimento, ajudando muito em sua compreensão.
Existem apenas duas diferenças entre a notação desse diagrama com o diagrama de
classes:
 Os objetos são escritos com seus nomes sublinhados
 Todas as instâncias num relacionamento são mostradas.
Com esse diagrama, temos o perfil do sistema em um certo momento de sua execução,
tendo a possibilidade, assim, de conferir se os dados estão atribuídos corretamente e se são
consistentes. Os diagramas de objetos têm seu nome sublinhado e todos os seus
relacionamentos são mostrados. Seus nomes vêm separados das classes que ele representa
por “:” (dois pontos). Nesse Diagrama, os atributos já podem se receber seus respectivos
valores.
Por exemplo, o cachorro que se chama Thor, você pode definir um objeto “Thor” e
representar ele aqui.
Por exemplo, Thor:Cachorro
Thor:Cachorro
Os diagramas de objetos são importantes para visualizar, especificar e documentar os
modelos estruturais, assim como aspectos dentro de um sistema.
Exemplo de um diagrama:
Thor:Cachorro
+cor: Castanho: string
Jessica:Dona
+peso: 37: int
+cpf:12345678901:int
+numCarteirinha:2345: int
latir()
comer()
correr()
8

10. O diagrama pode ser lido da seguinte maneira: O objeto Jéssica da classe Dona está
associado ao objeto Thor da classe Cachorro.
Podemos com os diagramas, projetar um jogo por exemplo. Onde o jogador está preso
em uma casa de tortura e ele deve tentar sair de lá.
O jogo tem as seguintes regras (não nos preocuparemos com objetos no jogo, somente
com o projeto da cena):
 A casa onde o jogador está possui dois quartos espelhados;
 Cada quarto reconhece quatro elementos da casa (uma porta, uma parede, ou outro
quarto);
 Se o jogador entra em um quarto, sua localização é alterada;
 Se ele entra em uma porta e a porta estiver
o Aberta: o jogador muda de quarto;
o Fechada: o jogador se machuca;
 Se o jogador se depara com a parede, se machuca.
Criando o diagrama de classes para esse jogo, temos:
<<interface>>
ElementoDoJogo 4 elementos
Joga()
1
Porta Quarto
Parede CasaEspelhada
estaAberta:boolean +QuartoNumero
QuartoUM:Elemento n 1
DeCasaEsp()
Entra() Entra()
Entra() getQuartoViz()
getQuartoViz() adicionaQuarto()
QuartoEspDoOutroLa
getQuarto(int):Quarto
do(:QuartoEsp)
A classe Quarto herda elementos da classe CasaEspelhada, e a Interface herda os elementos
de Parede . Porta tem uma relação de associação com Quarto, o que quer dizer que os
atributos de quarto e de porta se relacionam (Por exemplo, cada quarto possui uma porta).
Vários quartos dependem da existência de uma casaEspelhada e os elementos do jogo
dependem da existência de um quarto.
Podemos simplificar a visualização desse diagrama, criando o Diagrama de Objetos para esse
mesmo problema:
9

11.  Escolhemos o cenário que desejamos representar (casos de uso);
 Identificamos as classes (diagrama de classes);
 Defina os relacionamentos entre os objetos (tipos de relacionamento);
nJogo:JogosMortais
nArea:CasaEspelhada
+
QuartoUM:Quarto QuartoDOIS:Quarto
+ +
+ +
aPorta:Porta
+
:Parede :Parede :Parede :Parede :Parede
+ + + + +
O diagrama de objetos traz uma visualização muito mais sucinta do que será o projeto: A casa
espelhada possui dois quartos, e esses quartos devem reconhecer paredes, portas ou outro
quarto. E, por ultimo, devemos:
 Definir os nomes e valores para os atributos dos objetos;
10

12. Diagramas de Pacotes
O diagrama de pacotes mostra as relações entre diferentes pacotes e dependências
entre suas classes.
Os pacotes e dependências são importantes para fazer testes de sistema e visam
organizar o modelo de sistema UML. Com isso os desenvolvedores conseguem ver as
dependências do sistema em larga escala e minimizar impactos nas modificações.
Loja
O exemplo abaixo ilustra um diagrama de pacotes de uma loja qualquer onde cada
pacote é composto por um conjunto de classes. As setas representam a dependência entre os
mesmos.
Clientes Serviços
Produtos
11

13. Diagrama de Estrutura Composta
O Diagrama de estrutura composta mostra a estrutura interna de uma classe, ou seja,
como seus objetos estão interligados, com um objetivo comum. O diferencial desse diagrama é
que ele expressa tempo de execução, padrões de uso e o relacionamento entre os objetos.
Porém ele não é muito utilizado na prática, pois sua estrutura é bastante complexa.
A figura abaixo ilustra um exemplo de diagrama de estrutura composta, onde, por
exemplo, um usuário que imprimir um documento através de um programa de computador e
vai utilizar a impressora.
Computador
Programa Impressora
Neste outro exemplo, o objetivo é chegar a um diagnóstico do paciente, para isso
precisa de uma colaboração do médico com o paciente em uma consulta.
Médico Consulta Paciente
Diagnóstico
12

14. Diagrama de Componentes
O Diagrama de componentes da UML mostra como as classes deverão se encontrar
organizadas através da noção de componentes. O diagrama tem por objetivo apresentar a
disposição dos componentes físicos de um sistema, como interfaces e suas relações,
mostrando os elementos reutilizáveis de software e sua interdependência. Um componente
pode ser um pedaço de software retulizável, bem encapsulado e facilmente substituido.
O principal objetivo deste diagrama é 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. Um
componente é formado por um conjunto de classes que se encontram nele implementadas.
O componente em si pode ser um código em linguagem de programação como um
código executável já compilado. Por exemplo, em um sistema desenvolvido em Java, cada
arquivo .java ou .class é um componente do sistema. Exemplo de componente:
Cliente.java Graficos.dll
Um componente é mostrado em UML como um retângulo com uma elipse e dois
retângulos menores do seu lado esquerdo. Na figura abaixo segue uma forma de
representação mais antiga de componentes, temos o exemplo anterior e a seguinte forma:
Widget
No diagrama de componentes também é possível mostrar a configuração de um
sistema de software mostrando, graficamente, a dependência entre os diversos arquivos que
compõem o sistema, ou seja, um componente, assim como as classes que ele possui,
dependem funcionalmente das classes de outro componente.
13

15. Gerenciador
Gerenciador de
Graficos de Banco de
Comunicação
dados
Graficos.dll
Comm.dll
DB.dll
Aplicação
App.exe
No exemplo acima, a dependência entre componentes pode ser mostrada como uma
linha tracejada com uma seta, simbolizando que um componente precisa do outro para
possuir uma definição completa. Nota-se facilmente que arquivos .dll são necessários para
executar a aplicação.
Em outro tipo de notação, o diagrama é composto normalmente por componentes,
interfaces e portas. Os componentes são representados pelo estereótipo da uml <> . Interfaces
são representadas através de uma linha com um círculo ou semicírculo ligado ao componente.
Portas são representados através de retângulos saindo dos componentes.
Segundo MACORATTI, a UML reconhece cinco estereótipos de componentes:
 Um executável: Um componente que pode ser executado (um programa).
 Uma biblioteca: Uma biblioteca de classes ou funções, dinâmica ou estática.
 Uma tabela: Uma tabela de um banco de dados.
 Um documento: Uma parte da documentação (texto livre, diagramas, documentos de
ajuda, etc.)
 Um arquivo: Outros arquivos, geralmente, se trata de um arquivo de código fonte,
mas pode ser também um arquivo de dados, um ``script'' ou outros arquivos.
Exemplo de um diagrama de componente exibindo os componentes para um sistema de
locadora na web :
14

16. <<HTML>>
<<Aplication>>
Interface
GerenteDeBusca.java
Cliente.html
<<HTML>> <<HTML>>
InterfaceEstatica InterfaceDinamica
.html .html <<dataBase>>
BancoDeVideos.mdb
<<Aplication>>
MontaApplet
<<HTML>>
InterfaceExibida
.html <<Aplication>>
Servidor.java
<<Applet>> <<Aplication>>
Cliente.java TransmissorAV.java
Neste exemplo, utiliza-se << >> para falar o que é utilizado para implementar o
componente e, o nome do componente. Estas duas informações vão dentro de um retângulo.
Normalmente é utilizado para:
 Modelar os componentes do código-fonte, do código executável do software.
 Destacar a função de cada módulo para facilitar a sua reutilização.
 Auxiliar no processo de engenharia reversa, por meio da organização dos módulos do
sistema e seus relacionamentos.
15

17. Diagramas de Implantação
Um diagrama de implantação, também chamado de digrama de utilização, modela o
relacionamento entre recursos de infraestrutura, de rede ou artefatos de sistemas. Este
diagrama é normalmente utilizado em projetos onde há muita interdependência entre partes
de hardware e software. Cada nó deste diagrama é uma unidade física que representa um
recurso computacional, como processadores, dispositivos, roteadores ou qualquer
equipamento de importância para o sistema de software.
 Modela o mundo físico do sistema, considerando:
o Computadores
o Dispositivos e
o Suas interconexões
FAX
Terminal 1
Impressora Matricial
Servidor
Terminal 2
Impressora Laser
16

18. Diferenças entre os Diagramas
O diagrama de classes é o diagrama principal do modelo estrutural, ele é o diagrama
que chega mais perto do código do programa, onde é fácil visualizar as classes, seus métodos,
atributos e os relacionamentos, de acordo com a especificação do sistema podemos fazer uma
modelagem utilizando esses dados.
Os diagramas de Objetos são muito parecidos com os Diagramas de Classes, e são
usados, mormente, para exemplificar Diagramas de Classes mais complexos. Nos Diagramas de
Objetos, seus objetos recebem nomes reais e é muito mais fácil compreender as relações
entre eles.
Já os Diagramas de Pacotes, devem mostrar as relações entre pacotes e pacotes, ou
seja, a relação entre um grupo de classes ou outro grupo de classes através de uma relação de
dependência.
O principal objetivo do Diagrama de Estrutura Composta é mostrar a estrutura interna
de uma classe, a interligação de seus objetos.
Os Diagramas de Componentes apresentam a disposição dos componentes físicos de
um sistema, como interfaces e suas relações.
Os Diagramas de Implantação são utilizados, na maioria das vezes em projetos onde há
muita interdependência entre partes de hardware e software. Este diagrama modela o
relacionamento entre recursos de infraestrutura, de rede ou artefatos de sistemas.
17

19. Aplicação
Utilização da ferramenta case StarUML.
StarUML é uma plataforma de modelagem de software que suporta UML. Com ela você pode
modelar diagramas e ter uma melhor visualização dos mesmos.
Agência
+Número: int
+Nome: string
+Endereço: string
+abrirconta(cliente: Cliente, tipo: string): Conta
+obterCliente(id; int): Cliente
+autenticar(cliente: int, conta: int, senha: int): void
1
0..n
ContaBancária
+Titular: Cliente
+Número: int
+Dígito: int
+Saldo: float
+deposito(valor: float): void
+saque(valor: float): void
0..n
1..n Cliente
+Código: int
+CPF
+Nome: string
+Endereço: string
+obterConta(numero: int): void
18

20. Conclusões
A UML é uma ferramenta adequada para poder visualizar características de
comportamento de um software ou sistema, por isso é considerada uma das linguagens mais
expressivas no quesito modelagem.
Muitas técnicas avançadas de modelagem podem ser definidas usando UML como
base, podendo ser estendida sem se fazer necessário redefinir a sua estrutura interna. A
ferramenta integrou muitas idéias adversas, e esta integração acelera o uso do
desenvolvimento de softwares orientados a objetos. Mostra uma relação de dependência
entre os diagramas que a compõe (Pacote, componente, implantação, etc.), seja de
modelagem ou infraestrutura física do sistema.
Os diagramas UML permite em si que a construção de um sistema possa ser eficiente,
justamente por permitir uma detalhada análise de requisitos principalmente para linguagens
orientadas a objeto, além de facilitar a comunicação entre todas as pessoas envolvidas no
processo. A UML é método satisfatório para construção de sistema.
19

21. Referências Bibliográficas
Principais:
http://staruml.sourceforge.net
SILVA, R. P. e. UML 2 em Modelagem Orientada a Objetos. Florian ́ polis: Visual Books, 2007.
VARGAS, Thânia Clair de Souza. A história de UML e seus diagramas .
BOOCH, G.; RUMBAUGH,J.; JACOBSON,I. UML Guia do Usuário.2.ed. Rio de Janeiro:Elsevier,
2006.
PFLEEGER, S.L.Engenharia de Software - Teoria e Prática. 2.ed. São Paulo: Prentice Hall,2004.
CRAIG, L. Utilizando UML e padrões - Uma introdução à análise e ao projeto orientados a
objetos e ao desenvolvimento iterativo.
BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. – Rio de Janeiro :
Elsevier, 2003.
PENDER, Tom. UML A Bíblia – Rio de Janeiro:Elsevier, 2004.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML Guia do Usuário. – Rio de Janeiro :
Elsevier, 2006.
MARTIN, James.; ODELL, James. Análise e Projeto Orientados a Objeto. 639 p. – São Paulo:
Makron Books, 1995.
Relevantes:
http://www.lavailama.com.br
http://pt.wikipedia.org
http://www.cassao.eti.br
http://irup.rsuzano.com
http://www.novatec.com.br
http://pt.wikipedia.org/wiki/Diagrama_de_objetos
http://techblog.desenvolvedores.net/2011/05/28/diagrama-de-objeto-uml/
http://portalarquiteto.blogspot.com.br/2008/03/diagrama-de-objetos.html
http://www.portalarquiteto.com.br/diagrama-de-componentes/
http://www.etelg.com.br/paginaete/downloads/informatica/apostila_uml.pdf
http://docs.kde.org/stable/pt_BR/kdesdk/umbrello/uml-elements.html
http://www.macoratti.net/net_uml3.htm
MELO, Ana Cristina. Desenvolvendo aplicações com UML. 255 p. – Rio de Janeiro: Brasport,
2002.
20