aula04

Prévia do material em texto

Met. para de Desenvolvimento de Software
4º Aula
Diagramas UML – parte 2
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
Olá pessoal,
Como você está? Esperamos que você tenha gostado da nossa 
introdução sobre UML. Nesta segunda parte, você aprenderá 
diagramas que modelam as interações entre objetos do sistema – 
através dos diagramas de sequência e de comunicação. Aprenderá 
ainda como funciona um diagrama de pacotes, o que é um diagrama 
de estados e como representar um ambiente onde o sistema será 
implementado, através do diagrama de implementação.
Se você tiver qualquer dúvida, entre em contato via quadro 
de avisos, certo? A sua participação é muito importante para nós.
Bons estudos!
170
27
Seções de estudo
1 - Diagrama de Sequência
1 – Diagrama de Sequência
2 – Diagrama de Comunicação
3 – Diagrama de [Máquina de] Estados
4 – Diagrama de Pacotes
5 – Diagrama de Implantação
6 – Outros Diagramas da UML
Mostra como é a interação entre vários sujeitos da 
comunicação ao longo do tempo. Seus principais objetivos 
são: documentar casos de uso, mostrar como os objetos do 
sistema se comunicam por meio de mensagens em ordenação 
temporal, validar se todas as operações das classes foram 
identificadas e declaradas ou ainda para validar a existência de 
um objeto necessário ao funcionamento do sistema. Não é 
necessário fazer diagramas de sequência para todos os casos 
de uso ou requisitos que aparecerem, apenas para aqueles mais 
complexos.
Na parte superior do diagrama, ficam os objetos, que são 
sujeitos participantes da comunicação. Basicamente, um objeto 
é representado por um retângulo, com um nome do objeto, 
seguido por dois-pontos e o nome da classe e qual instância. 
Por exemplo: um nome car1: Carro declara um objeto car1 da 
classe Carro.
Um objeto pode ter várias outras notações, como:
 São entidades externas que interagem ao 
sistema enviando ou recebendo dados. Podem 
ser os mesmos atores nos diagramas de Casos de 
Uso. Assim, são representados pela mesma forma, 
por um boneco-palito – porém são nomeados da 
mesma maneira. Eles podem interagir com outros 
atores e com classes de fronteira.
 Indica as 
classes ou objetos responsáveis pela interface 
entre o sistema de informação e seus usuários ou 
pela comunicação entre dois ou mais sistemas. É 
com objetos desse tipo que os atores vão interagir 
com o sistema. Normalmente, são janelas e 
formulários.
 São classes e objetos utilizados 
quando os desenvolvedores optam por separar 
as manipulações de dados, as regras do negócio 
e o sequenciamento de tarefas da interface de 
comunicação do sistema com o usuário, realizando 
assim, todas as outras tarefas que um sistema fará.
 Indica classes ou objetos responsáveis 
por armazenar e gerenciar os dados do sistema, 
bem como por mostrar a estrutura lógica e estática 
dos dados, colaborando para a compreensão do 
que o sistema deve oferecer aos seus usuários.
Abaixo de cada objeto, fica uma linha tracejada 
verticalmente. É a linha da vida do objeto, mostrando 
qual a sequência na qual a vida do objeto durante a iteração 
é representada. Ele pode representar também a criação e a 
destruição de objetos. No momento em que o objeto participa 
da iteração, a linha da vida é coberta por um retângulo, que 
mostra o tempo em que o objeto interage com um outro 
objeto.
As linhas que percorrem de uma linha da vida a outra 
são chamadas de mensagens. Elas representam os serviços 
solicitados de um objeto a outro ou a ele mesmo, e as 
respostas desenvolvidas para as solicitações. Normalmente, 
o objeto origem que dispara a mensagem e o objeto destino 
que recebe a mensagem são diferentes, mas uma mensagem 
pode ter como objeto destino o mesmo objeto que disparou a 
mensagem. Esse caso é denominado de autochamada.
Uma mensagem consiste em uma linha reta, partindo 
do objeto origem para o objeto de destino, com uma seta 
apontando para esse objeto. Junto com essa reta, é escrito 
um rótulo contendo um nome da mensagem, podendo ter os 
seus parâmetros, mas isso é opcional.
Além dos parâmetros, podemos ter condições de guarda, 
que apresenta uma condição que deve ser satisfeita para que 
uma mensagem seja enviada. É demonstrada entre colchetes 
antes do rótulo da mensagem a ser enviada. 
Trechos de iteração podem conter uma moldura, onde 
essa moldura confere um novo sentido ao trecho que é 
coberto por essa moldura. Cada moldura recebe uma etiqueta 
que indica o que significará esse trecho. As etiquetas mais 
utilizadas são:
sentidos, dependendo da situação. No exemplo abaixo, é 
verificado se o usuário é um associado da entidade. Se sim, é 
conferido um desconto de 30%, caso contrário, o boleto virá 
no valor normal.
várias vezes. A condição de repetição é expressa do lado da 
etiqueta. Nesse exemplo, o loop vai de 1 até 3. Além disso, 
há uma condição de guarda especial que indica que o loop só 
será executado caso o medicamento seja de controle especial.
171
28Met. para de Desenvolvimento de Software
Vamos agora mostrar os diagramas de sequências para 
o nosso estudo de caso da locadora. No nosso caso, foram 
feitos dois diagramas, sendo que o primeiro foi criado para 
representar o processo de cadastro da locação. Nessa situação, 
foram identificados os objetos Funcionário, uma classe de 
fronteira para realizar o cadastro de locação, e dois objetos 
das classes Cliente e Carro. Durante a operação, será criado 
um objeto da classe Locação – indicado por meio de uma 
mensagem com o estereótipo <<create>>.
Nesta operação, são executadas as seguintes tarefas:
1. O funcionário informa o número do cliente, podendo 
2. O sistema busca e exibe os dados do cliente de acordo 
4. O sistema busca e exibe os dados do carro cadastrado 
6. O sistema salva os dados, criando uma nova instância 
de Locação com os dados selecionados.
A segunda operação que o analista documentou por 
meio de um diagrama de sequência foi o ato da devolução 
da locação, representado pelo caso de uso geral Encerrar 
Locação. Nesse caso de uso participam como objetos, um 
funcionário, a classe de fronteira responsável por fazer a 
interface do funcionário com o sistema, e as classes Carro, 
Locação e Cliente.
Nesse caso de uso, são especificadas as seguintes 
operações:
1. O funcionário informa o número de identificação 
3. O sistema buscará todas as locações que o cliente 
4. O sistema buscará os carros que foram locados pelo 
cliente. A partir daí, o sistema exibe os dados das locações e 
5. O funcionário informa a placa do carro locado 
e a quilometragem percorrida e marca a devolução como 
172
29
6. O sistema chama o método encerrar da classe 
Locação, para concluir o processo e computar o preço que 
o cliente deverá pagar. Esse preço é exibido na tela após a 
conclusão do processo.
Encerramos aqui nosso estudo sobre o diagrama de 
sequência. Na próxima seção, apresentaremos o diagrama de 
comunicação.
2 - Diagrama de Comunicação
É similar ao diagrama de sequência, possuindo o mesmo 
objetivo desse diagrama, que é mostrar a comunicação entre 
os objetos em um sistema de informação. Mas, essa exibição é 
feita de maneiras distintas. Enquanto que em um diagrama de 
sequência é mostrado o fluxo de mensagens entre os objetos 
no decorrer do tempo, a ênfase do diagrama de comunicação é 
mostrar como os objetos estão vinculados e quais mensagens 
são trocadas entre si durante o processo. Podemos assim dizer 
que esse diagrama é uma versão simplificada do diagrama de 
sequência.
Assim, devemos atentar a esses pontos quando criamos 
um diagrama de comunicação:
Fronteira, Classe de Sistema e entidade – são mostrados de 
ligamos uma linha reta entre eles. A partir daí, um objeto pode 
mandar mensagens para outro objeto. Essas mensagens são 
indicadas por uma linha reta, com uma seta apontando para o 
objeto destino. Não há distinção entre mensagens normais e 
de execução das mensagens no sistema e deve ter um nome 
para identificação. Assim como no diagrama de sequência,pode-se especificar parâmetros na chamada da mensagem.
Para demonstrar o uso do diagrama de comunicação, 
observe a próxima figura. Ele é um diagrama de comunicação 
para a funcionalidade de cadastro de locação, para o qual já 
foi feito um diagrama de sequência, que se encontra na seção 
anterior. Ele descreve as mesmas etapas que descrevemos 
anteriormente. Aproveite para ver o diagrama de sequência e 
observe as diferenças entre os dois.
173
30Met. para de Desenvolvimento de Software
3 - 
Antes de iniciarmos os nossos estudos sobre esse 
diagrama, explicaremos o que significa um estado. Um estado 
é entendido como um período de tempo pelo qual um objeto 
espera por um evento, permanecendo em uma situação por 
um determinado tempo. Muitos objetos ou situações que 
vemos em nossa vida possuem estados: Uma piscina pode 
estar cheia ou vazia, uma ordem de serviço pode estar ativa, 
concluída ou cancelada, uma atividade que você faz na 
nossa disciplina pode constar como não enviada, enviada e 
aguardando avaliação e avaliada etc.
Especificar um estado de um objeto faz parte do 
comportamento dinâmico de um sistema de informação (o 
comportamento estático é representado pelo diagrama de 
classes, que você viu na nossa Aula 03). Para isso, é criado 
um modelo de estados que consiste em um conjunto de 
diagramas de estados. 
Um diagrama de estado tem como função ilustrar o 
comportamento dos objetos quando reagem a estímulos 
externos a eles, e quais mudanças de situações podem ocorrer 
em um objeto de uma classe durante seu ciclo de vida. Um 
diagrama de estados é atribuído a uma classe, mas nem 
todas precisam de um diagrama desse tipo. Normalmente, 
as principais classes de um sistema comercial possuem 
comportamento dinâmico, ou seja, mudam de estado, porém, 
em um sistema de tempo real, a maioria das classes desse 
sistema possui um ciclo de vida.
Assim como em todos os diagramas da UML, um 
diagrama de estados contém vários elementos. Vejamos quais 
são esses elementos a partir de agora.
Estado inicial
É indicado por meio de um círculo preenchido, marcando 
o início do diagrama.
Estado final
Indicado por um círculo preenchido dentro de um 
círculo vazado, é um símbolo que marca o ponto final dos 
estados modelados.
Estado 
Marca a situação ou a condição que um objeto do sistema 
se encontra em um determinado momento. Góes (2014) 
elenca as situações que podem ser ilustradas por um estado:
– a exemplo, o objeto ordem de serviço 
aguardando a sua triagem, ou seja, o seu envio 
diariamente via e-mail o diretor da área para 
que faça a aprovação ou o cancelamento das 
A satisfação de alguma condição – a exemplo, 
o objeto ordem de serviço sendo cancelado 
pelo sistema após dez dias sem aprovação ou 
conta-corrente se tornando ‘positiva’ à medida 
que um depósito ocorrer (GÓES, 2014, p. 219).
Um estado é representado na UML por um retângulo de 
bordas arredondadas, dividido por uma linha de uma forma 
horizontal. Na parte superior é escrito seu nome, que serve 
para distinguir um estado de outros. Já na parte inferior, são 
listadas as tarefas que um objeto executará no estado – não 
sendo obrigatória sua especificação. Essas tarefas podem ser 
escritas em formato de lista e devem ser precedidas pelas 
seguintes cláusulas:
continuamente, enquanto que o objeto permanecer nesse 
quando o objeto deixar o estado.
Um estado pode conter um conjunto de estados internos 
– ou seja, um outro diagrama de estados dentro desse estado. 
A essa situação denominamos o nome de estado composto. 
Transições
Indica um relacionamento entre dois estados, 
demonstrando um evento que proporcionou a mudança de 
um estado para outro. É representado por uma linha reta, que 
liga os dois estados, com uma seta apontando para o estado 
que o objeto entrará quando um evento for concretizado. Esse 
evento é descrito junto com a linha. 
Em uma transição, pode conter também uma condição 
adicional da guarda que deve ser satisfeita para que a transição 
seja realizada. Para isso, a condição de guarda é descrita entre 
colchetes. A diferença entre uma condição de guarda e um 
evento é que enquanto um evento é verificado continuamente, 
à espera que seja concretizada, a condição de guarda somente 
é verificada uma vez.
Pseudo estado de escolha
Indica que uma decisão deve ser tomada. É indicada por 
meio de um losango.
Para demonstrarmos o uso de um diagrama de estados, 
criamos um diagrama de máquina de estados simples para a 
classe Carro. Nesse diagrama, podem-se observar as seguintes 
situações:
indisponível. Mas ele pode retornar a condição de disponível 
perda, roubo ou dano desse carro, ele passa a ser inservível, 
perdurando assim até o fim de sua vida.
174
31
Vamos ver agora o Diagrama de Pacotes, que é uma forma 
de agrupar elementos na UML.
4 - Diagrama de Pacotes
Um diagrama de pacotes consiste em dividir um sistema 
complexo em partes menores denominadas de pacotes. Um 
pacote representa um grupo de elementos que podem se 
relacionar com outros pacotes por meio de uma relação de 
dependência. Esses elementos que estão em um pacote podem 
ser classes, casos de uso, diagramas ou outros pacotes. Para que 
você saiba da importância deles, a UML teve seus elementos 
divididos em pacotes.
Um pacote é representado graficamente na UML por 
meio de um retângulo, com uma aba no seu canto superior 
esquerdo, onde seu nome pode estar no centro do retângulo 
maior ou na aba sobre o retângulo. Assim, podemos dizer que 
um pacote na UML tem um formato similar a uma pasta. A 
partir do momento em que um elemento se encontra dentro 
de um pacote, devemos referenciá-lo pelo nome desse pacote. 
Por exemplo, se uma classe Carro está num pacote chamado 
Entidades, devemos referenciá-lo nessa classe escrevendo 
Entidades: Carro.
No exemplo abaixo, é mostrado um diagrama de 
pacotes que agrupa logicamente os casos de uso (que foram 
identificados na aula 2) em dois pacotes: o sistema de cadastro, 
que envolve os cadastros de carro, funcionário e cliente, e 
o sistema de locação, envolvendo as rotinas de cadastro de 
locação e encerramento de locação.
175
32Met. para de Desenvolvimento de Software
Até o momento, você viu apenas diagramas que 
documentam requisitos funcionais. Na seção a seguir, veremos 
um diagrama que mostra os requisitos não funcionais.
5 - Diagrama de Implantação
Tem como objetivo ilustrar o ambiente de software, 
redes e hardware onde o software será executado, permitindo 
que os programadores criem condições favoráveis a sua 
implantação. Ao contrário de todos os demais diagramas que 
você viu anteriormente, ele é mais relacionado aos requisitos 
não funcionais do que os requisitos funcionais.
A base geral a de um diagrama de implantação são os 
nós, que são retângulos. Um nó pode ter dentro dele vários 
outros nós. Ele possui um nome que o identifica, e um 
estereótipo, que marca qual é o tipo de objeto que o nó está 
representando. Vejamos alguns deles:
mundo físico, usados /ou resultantes de um processo 
de desenvolvimento. Por exemplo: Programas fontes, 
executáveis, tabela de banco de dados, scripts, documento do 
sistema, etc.
de um nó. Podem especificar atributos de um dispositivo 
computacional – que veremos adiante. Assim, podemos 
representar sistemas operacionais, sistemas gerenciadores de 
banco de dados etc.
computacional (servidores, roteadores, computadores etc.)
Esses nós são conectados por meio de associações, para criar 
caminhos de comunicação e sistemas em rede. Essas conexões 
são representadas por linhas retas que partem de um nó para 
outro no diagrama, e recebem um nome com o modelo dessa 
associação. Normalmente, essa relação é usada para descrever 
uma conexão entre dois dispositivos computacionais.
Agora vamos mostrar o diagrama de implantação para 
o sistema da locadora. Para que esse diagrama fosse feito, o 
analista teve que coletar algumas informações em relação ao 
ambiente onde o futuro sistema será implementado:
de Dados. Esse servidorusará o gerenciador de banco de 
dita, tendo como sistema operacional o Ubuntu Server 16.04, 
executando o servidor web Apache 2.4 e o interpretador 
PHP 7.1. Essa dupla fará com que o sistema da locadora seja 
sistema terão o Windows 7 64-bits instalado e usarão o 
ligados a um switch Gigabit de 36 portas, por meio de cabos 
TCP/IP de par trançado de 10/100Mbps.
A figura a seguir mostra o diagrama de implantação para 
essa situação do sistema:
176
33
Agora, para finalizar o nosso estudo, apresentaremos 
alguns outros diagramas que são previstos na UML.
6 - Outros Diagramas da UML
A UML também especifica outros diagramas, que são 
utilizados somente em situações específicas e não são tão 
amplamente utilizados quanto os outros diagramas que citamos 
aqui. Vamos citar alguns deles nesta seção.
Diagrama de Objetos: Mostra os objetos que foram 
instanciados das classes, mostrando o momento exato do 
sistema em um momento hipotético de execução. Ele tem 
a mesma notação que o diagrama de classes, com algumas 
diferenças:
escrever primeiro o nome do objeto, seguido por um sinal de 
dois-pontos e depois escrevemos o nome da classe à qual o 
objeto é instanciado.
Assim, se um objeto da classe Paciente toma 2 Remédios, as 
Diagrama de componentes: Mostra os componentes 
que vão integrar o software (podem ser frameworks, bibliotecas 
de terceiros, componentes de software, tabelas de banco de 
dados, seções do sistema etc). Esses componentes podem 
possuir interfaces (isto é, classes abstratas com operações) 
que permitem associações entre componentes do mesmo 
diagrama.
nome, separados por um sinal de igualdade.
177
34Met. para de Desenvolvimento de Software
Diagrama de Fluxo de Informações: É um diagrama 
que mostra a torça de informações entre as entidades do 
sistema (podendo ser uma classe, um ator etc.) em alguns 
níveis elevados de abstração. É um diagrama útil para 
informar a circulação de informações que há em um sistema. 
É composto por fluxos de informação (do inglês information 
flows, indicam para qual sentido navega uma informação) e 
itens de informação (que indicam informações adicionais 
dessa informação, chamado em inglês de information itens).
Com isso, finalizamos nosso estudo sobre UML. 
Esperamos que você tenha se interessado pelos diagramas 
que nós apresentamos nessas aulas. Nas próximas aulas, você 
aprenderá sobre as metodologias ágeis, um assunto que se 
tornou popular recentemente na Engenharia de Software.
Retomando a aula
1 – Diagrama de Sequência
Você observou que esse diagrama mostra como é a 
interação entre vários sujeitos da comunicação ao longo do 
tempo. Nesse tipo de diagrama podem conter objetos e em 
cada um deles, pode conter uma linha da vida. Esses objetos 
trocam mensagens entre si durante toda a sua existência no 
sistema.
2 – Diagrama de Comunicação
Você estudou que o diagrama de comunicação é similar 
ao diagrama de sequência, compartilhando os mesmos 
objetivos, só que de maneiras diferentes. Enquanto que em 
um diagrama de sequência é mostrado o fluxo de mensagens 
entre os objetos no decorrer do tempo, a ênfase do diagrama 
de comunicação é mostrar como os objetos estão vinculados 
e quais mensagens são trocadas entre si durante o processo.
3 – Diagrama de [Máquina de] Estados
Aqui, você viu que um Diagrama de Máquina de Estados 
consiste em um diagrama que apresenta o comportamento 
dinâmico de um objeto, apresentando em quais estados um 
objeto de uma determinada classe pode estar ao longo do seu 
ciclo de vida. 
4 – Diagrama de Pacotes
Um diagrama de pacotes consiste em dividir um sistema 
complexo em partes menores denominadas de pacotes, sendo 
que um pacote pode agrupar logicamente casos de uso, classes, 
diagramas e outros pacotes.
5 – Diagrama de Implantação
Tem como objetivo ilustrar o ambiente de software, redes 
e hardware onde o software será executado, permitindo que os 
programadores criem condições favoráveis a sua implantação. 
É um diagrama mais relacionado aos requisitos não funcionais 
do que a dos requisitos funcionais.
6 – Outros Diagramas da UML
A UML oferece vários outros diagramas, como Diagrama 
de Objetos, Diagrama de Componentes, Diagrama de Fluxo 
de Informações, entre outros.
PRESSMAN, Roger. Engenharia de Software. São Paulo-
SP: Makron Books, 2006.
SOMMERVILLE, I. Engenharia de Software. 8ª Edição. 
Addison Wesley, 2007.
James. UML – guia do usuário. Rio de Janeiro: Elsevier, 2012.
UML e 
C++-Guia prático de desenvolvimento orientado a objeto. São Paulo: 
Makron, 2002.
ENGHOLM JR, Hélio. Engenharia de Software na prática. 
São Paulo: Novatec Editora, 2010.
GÓES, Wilson Moraes. Aprenda UML por meio de estudos 
de caso. São Paulo: Novatec Editora, 2014.
BALZERT, Heide. UML 2: compacto. Rio de Janeiro: 
Elsevier, 2007.
Vale a pena
Vale a pena ler
Vale a pena acessar
FAKHROUTDINOV, Kirill. UML Information Flow 
Diagrams - Overview of Graphical Notation. [S.l.]: UML 
Diagrams, [s.d.]. Disponível em: <http://www.uml-diagrams.
org/information-flow-diagrams.html>. Acesso em: 04 out. 
2017.
MACEDO, Diego. Introdução a UML e seus diagramas 
- Diego Macêdo - Analista de T.I. [S.l.]: Diego Macedo, 
2012. Disponível em: <http://www.diegomacedo.com.br/
introducao-a-uml-e-seus-diagramas/>. Acesso em: 04 out. 
2017.
178