MOD - 02 - Slides Aulas - Prof. Welton Duque

ii.
1
Prof. Welton Duque
Modelos e Linguagens de
Programação
Prof. Eng⁰ Welton Sthel Duque

2º Semestre de 2017
ii.2
Prof. Welton Duque
Notações Gráficas em
Linguagens de Programação
UML - Unified Modeling

Language
Modelagem de Software ii.3
Prof. Welton Duque
O que é Modelagem de sistemas?
• A maior parte dos problemas encontrados em
sistemas orientados a objetos são causados
durante a construção do modelo do sistema
• É comum empresas e profissionais não se
preocuparem com a fase de modelagem do
projeto e acabam cometendo erros de análise
• Muitos profissionais iniciam erroneamente o
desenvolvimento de projetos já pela fase de
codificação, causando grandes riscos à
evolução e à manutenção natural do software
Prof. Welton Duque
O que é Modelagem de sistemas?
• É o processo de desenvolvimento de modelos
abstratos, em que cada modelo representa uma
perspectiva diferente do mesmo sistema
(SOMMERVILLE, 2011)
• Cada modelo será representado por um notação
gráfica própria, que, quase sempre, nos dias atuais,
está baseada na UML (Unified Modeling Language)
• Os modelos são úteis para a elicitação de requisitos
durante a fase de projeto; ou para documentar a
estrutura e a operação de sistemas já existentes
• É possível implementar um sistema real, de forma
completa ou parcial, por meio de processos de
engenharia de software dirigidos a modelos
Prof. Welton Duque
Diferentes Perspectivas a serem modeladas
• Externa: modela todo o ambiente externo dentro
do qual o com o qual o sistema irá funcionar
• Estrutural: modela as estruturas de dados e os
componentes físicos do sistema
• Interação: modela as interações entre o sistema e o
seu ambiente externo, e entre os componentes
internos deste sistema (o quê fazer)
• Comportamental: modela o comportamento
dinâmico e a forma como o sistema reage aos
eventos internos e externos (como fazer)
• Cada perspectiva acima possui a sua própria
notação gráfica e cada uma pode ser modelada de
forma independente, em um projeto de sistema
Prof. Welton Duque
UML - Unified Modeling Language
• A UML é a linguagem mundial e padrão, usada para
a modelagem de sistemas orientados a objetos
• Possui notações gráficas padronizadas para cada
uma das diferentes perspectivas de um sistema
• Abrange todas as visões necessárias ao
desenvolvimento e à implantação do sistema
• Adequada à modelagem de quaisquer sistemas de
informação, concorrentes, distribuídos, aplicações
web, corporativos, complexos, de tempo real, etc.
• Não é uma metodologia de desenvolvimento e não
especifica "como" projetar um sistema
• Mas, auxilia na visualização e interação de todos os
seus componentes internos e externos
Prof. Welton Duque
História da UML
• A UML foi criada em 1996 (v0.9), a partir da união de
diferentes e consagradas técnicas de engenharia de
software (Rational Software Corporation), que provaram
seu sucesso na modelagem de sistemas complexos:
– James Rumbaugh - Object Modeling Technique (OMT),
25 anos de como pesquisador da GE, depois IBM (1994)
– Grady Booch - Booch Method (IBM)
– Ivar Jacobson - Objectory (OOSE) Process, pesquisador
da Ericsson, depois IBM (1995)
• Em 1997, gigantes como Microsoft, Oracle, IBM, HP, etc.,
adotam o padrão UML 1.0
• Em 2000, foi aprovada pelo OMG (Object Management
Group), um consórcio internacional de empresas que
definem padrões de sistemas
• Em Março de 2015, foi lançadas a sua mais recente versão
(v2.5), gratuitamente disponível em http://www.omg.org
Prof. Welton Duque
Versão atual da UML
• Versão 2.5: documento de 752 páginas (in english) disponível
gratuitamente em http://www.omg.org/spec/UML/2.5/PDF
• Portal Acadêmico (pdf): MOD_UML formal v2.5 Mar15.pdf
• O OMG também disponibiliza outros padrões consagrados pela
indústria de desenvolvimento de softwares:
Prof. Welton Duque
Diagramas da UML 2.5
Prof. Welton Duque
Etapas de desenvolvimento de um sistema
Levantamento de Requisitos
Análise
Capturar as
características Projeto
que definem Entender e
refinar os Testes
"o que" o Determinar
sistema deve requisitos do Implementação
sistema "como" o
fazer sistema Verificar se os
atenderá os requisitos
foram Disponibilizar
requisitos o sistema para
(desenvolver o atendidos
os usuários
software)
Prof. Welton Duque
Diagramas da UML 2.5
Diagramas Estruturais:
• Representam os aspectos estáticos do sistema, sua
estrutura de dados, funções, relacionamento entre
seus componentes, etc.
• Tipos: classes, objetos, pacotes, estrutura
composta, componentes, implantação e perfil
Diagramas Comportamentais:
• Representam os aspectos dinâmicos do sistema em
estado de execução, suas respostas a estímulos do
ambiente e as interações entre os componentes
definidos nos diagramas estruturais
• Tipos: casos de uso, estados, atividades, sequência,
comunicação, temporização e interação
Prof. Welton Duque
Diagramas da UML
Diagramas Arquiteturais (são estáticos):
• Mostram a organização dos componentes
executáveis do sistema, sua localização física, nós
de armazenamento com os quais interagem, etc.
• São produzidos já a partir do início da fase de
desenvolvimento do sistema
• São atualizados durante o projeto, para indicar a
arquitetura física pretendida
• Tipos: estrutura composta, pacotes e implantação
Prof. Welton Duque
Ferramentas de diagramação UML
Comerciais:
 Rational Rose (IBM)
 Together (Borland)
 Visual Paradigm
 Visual Architect
 Enterprise Architect 10 (Sparx Systems)
 Describe (Embarcadero)
 System Architect (Choose Technologies)
 Astah (Change Vision - 50 days trial - antigo Jude)
 Viso (Microsoft)
Open Source (http://www.sourceforge.net/):
 ArgoUML
 StarUML
 Umbrello (for KDE)
 Poseidon (Gentleware)
 Dia UML
Online / Free
 Lucidchart (https://www.lucidchart.com)
 yEd (https://www.yworks.com)
 Dia UML
Prof. Welton Duque
Diagramas da UML
Em nossa disciplina, abordaremos os cinco diagramas mais
utilizados e suficientes para a modelagem de aplicações:
• Diagrama de Casos de Uso (Use Cases): mostram as
interações do ambiente com o sistema, descrevendo como
seu comportamento funcional é visto pelo usuário externo
• Diagrama de Classes: mostram a estrutura estática do
sistema, representada por suas classes, objetos, atributos e
associações entre as classes
• Diagrama de Sequência: comportamento dinâmico entre
os usuários, objetos e demais componentes do sistema
• Diagrama de Estados: comportamento dinâmico de um
objeto e como este reage aos eventos internos e externos
• Diagrama de Atividades: comportamento dinâmico do
fluxo de atividades de um processo (fluxos de trabalho)
ii.15
Prof. Welton Duque
Diagrama de Casos de Uso

"Use Case" Diagrams
Casos de Uso ii.16
Prof. Welton Duque
• Documentam tudo o que o sistema faz do ponto de vista
do usuário externo, sem revelar a estrutura e o
comportamento interno deste sistema (quem faz "o quê")
• São bastante usados no suporte à elicitação de requisitos,
na comunicação com clientes e na realização de testes
Cenário: é uma das sequências possíveis de eventos
que ocorrem quando o usuário interage com o
sistema (é uma instância do caso de uso)
Ator: representa um papel, uma entidade externa,
que interage com o sistema, podendo ser pessoas,
outros sistemas, organizações, equipamentos, etc.
Passageiro Caso de Uso: é o nome de um tarefa discreta, com
verbo e objeto, que pode ser realizada por um ator
Comunicação: liga um ator a um caso de uso, por
meio de uma linha contínua ou tracejada
Compra O Diagrama de Casos de Uso representa
Passagem todos os casos de uso juntos, que descrevem
completamente toda a funcionalidade do
sistema modelado
Casos de Uso ii.17
Prof. Welton Duque
• A coleção dos use cases deve especificar todas as formas
possíveis de uso do sistema, por meio de notações gráficas
padrão, conforme os exemplos abaixo:
Solicitar Verificar
Matricular aluno
histórico pré-requisitos
• Os Atores são entidades do ambiente do sistema, podendo

representar pessoas (papéis) ou outros subsistemas que
interagem com o sistema em desenvolvimento:
<<Ator>>
Coordenador
Sistema de controle
Professora Secretária Estudante
de pre-requisitos
Casos de Uso ii.18
Prof. Welton Duque
Exemplo da Clínica "Boa Saúde"
Exemplo de modelagem de Casos de Uso: A clínica médica
"Boa Saúde" deseja contratar um(a) engenheiro(a) de
computação para desenvolver um sistema de agendamento
de consultas e exames. Neste sistema, o paciente entra em
contato com a clínica para marcar consultas com seu(sua)
médico(a) de preferência. A secretária procura a data e hora
disponível mais próxima na agenda e marca a consulta. Por
fim, o paciente realiza a consulta e poderá receber, ou não, as
prescrições médicas e solicitações de exames do médico.
• Só de "ler" atentamente o enunciado, é possível identificar
os sujeitos das orações, que podem representar os atores
do sistema:
Paciente Médico Secretária

Casos de Uso ii.19
Prof. Welton Duque
• Só de "ler" atentamente o enunciado, também é possível
identificar os verbos das orações, que representam as
ações realizadas pelos atores (sujeitos):
Solicita Consulta
Solicita Cancelamento de Consulta
Paciente
Consulta Agenda
Marca Consulta
Cancela Consulta
Secretária
Realiza Consulta
Prescreve Medicamento
Solicita Exame
Médico
Diagrama de Casos de Uso ii.20
Prof. Welton Duque
O Diagrama Composto de
Casos de Uso representa todos
os casos de uso juntos, que
descrevem completamente
todos os requisitos funcionais
do sistema modelado
Todas as comunicações
entre os atores e o sistema
são bidirecionais e por cada
uma delas fluem todos os
dados previstos entre o ator
e o sistema
A direção da seta indica o

sentido do primeiro fluxo de
dados, proveniente do ator
que inicia o caso de uso
Fonte: http://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408
Diagrama de Casos de Uso
Exemplo da Clínica "Boa Saúde" ii.21
Prof. Welton Duque
Include: define que um

caso de uso, para ter a sua
funcionalidade executada,
precisará chamar outro
caso de uso
Os diversos casos de uso

de um diagrama também
podem ser iniciados por
vários atores diferentes
Fonte: http://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408
Prof. Welton Duque
Cada Caso de Uso deve possuir:
• O nome do ator com seu desenho de "palitinhos" (sujeito)
• Nome da interação dentro da "elipse" (verbo de ação)
• Linha que conecta o "palitinho" à "elipse" (comunicação)
• A linha pode ter uma seta em uma das pontas para indicar
quem inicia a operação (comunicação sempre bidirecional)
• Um caso de uso pode ter um ou mais cenários, sendo, por
exemplo, um cenário para descrever o uso normal e outros
cenários para descreverem os casos de exceções
• Casos de uso não são eficazes para elicitar restrições ou
regras de negócio, pois oferecem apenas visões simples da
interação entre os usuários (atores) e o sistema
• Para cada caso de uso, é necessário fornecer dados
complementares para a sua compreensão, que podem
incluir resumos textuais, tabelas e diagramas de sequência
Prof. Welton Duque
Dados complementares
Informações complementares
Caso de Uso: Transferir Dados
Prof. Welton Duque
Dados complementares para os casos de uso
o Nome o Fluxo Principal

o Descrição o Fluxos Alternativos
o Identificador o Fluxos de Exceção
o Importância o Pós-condições
o Sumário o Regras do Negócio
o Ator Primário o Histórico
o Atores Secundários o Notas de
o Pré-condições Implementação
utros exemplos de Casos de Uso Sistema de Gestão de Matrículas
ii.25
Prof. Welton Duque
caso de uso extensor
Solicitar <<extends>>
Solicitar histórico do
histórico semestre atual
caso de uso
estendido <<extends>> caso de uso extensor
Estudante Solicitar histórico de
todos os semestres
Matricular
<<include>> aluno
Verificar caso de uso base
dependências
Sistema de controle caso de uso incluído
de pré-requisitos Secretária
<<include>>: define que um <<extends>>: significa que o caso

caso de uso base, para ter a de uso estendido contém diferentes
sua funcionalidade executada, cenários e cada um deles poderá
precisará chamar outro caso incorporar o comportamento
de uso (incluído). A notação é especificado pelos casos de uso
de uma linha tracejada. extensores (linha tracejada)
Prof. Welton Duque
Relacionamentos de Inclusão: <<include>>
• Quando dois ou mais casos de uso incluem uma sequência
comum de interações, esta sequência comum pode ser
descrita em um outro caso de uso
• O caso de uso comum evita a descrição repetida de uma
mesma sequência de interações e torna a descrição dos
casos de uso mais simples (reuso de comportamentos)
• Exemplo: Em um sistema bancário, os casos de uso "Obter
Extrato", "Realizar Saque" e "Realizar Transferência" usarão
o caso de uso comum "Validar a senha do cliente"
caso de uso base
Matricular
<<include>> aluno
Verificar
dependências
caso de uso incluído
Secretária
Prof. Welton Duque
Prof. Welton Duque
• O <<include>> aponta para os
comportamentos que podem ser
usados por mais de um caso de uso
• O <<include>> serve para fatorar
Passageiro o reuso de comportamentos, e não
tem relação alguma com o
tratamento de exceções
Comprar Cartão de
Passagem Múltipla • A flecha do <<include>> parte do
comportamento principal e aponta
Comprar Cartão de para o comportamento reutilizado
Passagem Simples (fatorado)
<<include>> • De maneira oposta ao include, a seta
<<include>> do <<extends>> é diferente, pois
aponta para o comportamento
principal
Realizar
Pagamento
<<extends>> <<extends>>
<<extends>>
Sistema
Indisponível Limite de
Não aprovado Saldo
Prof. Welton Duque
Relacionamentos de Extensão: <<extends>>
• Cada uma das diferentes sequências (extensor) representa
um comportamento opcional, que só ocorre sob certas
condições ou cuja realização dependa da escolha do ator
• Quando um ator opta por executar a sequência de
interações definida no extensor, então este será executado
• Após a sua execução, o fluxo de interações volta ao caso de
uso estendido, recomeçando logo após o ponto em que o
extensor foi inserido
• Importante: não necessariamente o comportamento
definido pelo caso de uso extensor será sempre realizado
caso de uso extensor
Solicitar <<extends>>
Solicitar histórico do
histórico semestre atual
caso de uso
estendido <<extends>> caso de uso extensor
Solicitar histórico de
todos os semestres
Estudante
Prof. Welton Duque
Prof. Welton Duque
• Os casos de uso extensores representam
comportamentos de exceção, ou que sejam
realizados com base nas escolhas dos
atores, quando estes interagem com o caso
de uso principal (estendido)
Passageiro • Os comportamentos de exceção devem ser
fatorados à parte do caso de uso principal
estendido • A seta do <<extends>> está apontada
para o caso de uso principal (estendido)
Comprar
Passagem • Os casos de uso extensores (exceções)
também podem estender mais de um caso
de uso principal (estendido)
<<extends>>
<<extends>>
<<extends>>
Fora de Tempo
Serviço <<extends>> Excedido
extensor
Transporte Pagamento
Cancelado não aceito
Prof. Welton Duque
Casos de Uso "Manter"
• São os casos de uso criados para reunir as operações de
cadastro, consulta, alteração e exclusão de informações de
bancos de dados do sistema
<<include>> Manter
Manter Informações
Cliente de Contato
Manter
Conta bancária
Gerente
de Conta
Manter Perfil Cliente

de Investimento
Prof. Welton Duque
Generalização de Use Cases
• É possível definir tipos gerais de atores e depois
especializá-los usando o relacionamento de especialização
• Segue o mesmo conceito de herança de classes, em que o
ator filho herda os comportamentos do ator pai
• O filho deverá acrescentar ou sobrescrever o
comportamento do pai
• O pai pode substituir o filho em qualquer lugar em que o
pai apareça no sistema
Abertura
de Conta
Cliente
Conta Especial Conta Poupança

Cliente Especial
Prof. Welton Duque
Levantamento de elementos dos casos de uso
• Atores e casos de uso são identificados a partir de
informações coletadas do levantamento de requisitos
• Os analistas devem identificar as atividades do negócio,
que são relevantes para o sistema a ser construído
• Não existe uma regra geral que indique quantos casos de
uso são necessários para descrever um sistema (isso
depende da complexidade do sistema a ser construído)
• O analista deve identificar as áreas da empresa que serão
afetadas ou que serão usuárias do sistema (fontes e
destinos das informações processadas pelo novo sistema)
• Perguntas úteis: que órgãos, empresas ou pessoas irão
utilizar o sistema? Quais outros sistemas existentes se
comunicarão com o novo sistema? Quem deve ser
informado em caso de ocorrências? Quem está interessado
em um certo requisito funcional do sistema?
Prof. Welton Duque
Requisitos de desempenho
• Definição de requisitos de desempenho, frequências de
uso, tempos de execução, etc., para cada caso de uso:
ii.36
Prof. Welton Duque
Classes e
Diagrama de Classes
Diagrama de Classes ii.37
Prof. Welton Duque
• As classes são os elementos mais importantes de um

sistema orientado a objetos
• As classes são abstrações da realidade, que especificam a
estrutura dos objetos presentes no domínio do problema
• O Diagrama de Classes é o principal diagrama estrutural da
UML (modelagem estática)
• Esse diagrama mostra as classes, suas interfaces e seus
relacionamentos
• Uma classe contém atributos (propriedades), operações
(métodos), relacionamentos e semântica
• As classes são usadas para capturar o vocabulário e
requisitos de um sistema
• Capturar vocabulário = verbos (estrutura dinâmica) +
substantivos (estrutura estática)
Prof. Welton Duque
• Toda classe tem um nome único e exclusivo, dentro

do sistema ao qual ela pertence
• O nome da classe pode ser uma palavra isolada, ou
pode ser um nome extenso, precedido pelo nome
do pacote + "::", em que a classe está contida
• Um sistema completo possui pacotes e estes
possuem classes Nome da Classe
Pacote1::Forma (obrigatório)
Negocio::Conta
origem Atributos (opcional)
Negocio::Banco mover()
redimensionar() Operações (opcional)
Cliente exibir()
Prof. Welton Duque
• Cada atributo possui um tipo de dado
• Cada operação possui uma assinatura composta
por dados (parâmetros) de entrada e de retorno
(como o retorno de uma função)
Implementação em Java
public class Sala{
int codigoSala;
Nome da Classe (obrigatório)

public void consultarSalas(){...}
}
Atributos da Classe (opcional)
Implementação em Delphi
type
Operações da Classe (opcional)
TSala = class
private
codigoSala: integer;
public
procedure consultarSala;
Prof. Welton Duque
Atributos ou Propriedades
• Um atributo é uma variável ou uma estrutura de
informação de uma classe, que estará presente em
todos os objetos instanciados desta classe
• Em um dado momento (estado), um objeto conterá
valores próprios (diferentes de outros objetos da
mesma classe) para todos os atributos da sua classe
Atributos podem ser Ou podem, também, ter seus
identificados apenas tipos de dados e valores
com nomes padrão também definidos
Cliente Parede
nome altura : real
largura : real
endereço
espessura : real
telefone viga : boolean = false
Prof. Welton Duque
Operações ou Métodos
• Uma operação é um comportamento que pode ser dado a
um objeto instanciado de sua classe
• Um classe pode ter qualquer número de operações ou,
inclusive, nenhuma operação
• Operações são meios de alterar os valores de atributos e
de promover a comunicação entre diferentes objetos,
sejam da mesma classe ou de classes diferentes
Como nos atributos, pode-se Ou especificar a assinatura da
especificar uma operação operação, ou seja, seus parâmetros
apenas com o seu nome e tipos de entrada e de retorno
Retângulo Retângulo
mover() float mover(int x, int y)

aumentar() void aumentar(int percent)
diminuir() void diminuir(int percent)
Prof. Welton Duque
Visibilidade de Atributos e Operações
• Na UML, é possível usar notações que definem o tipo de
permissão de acesso aos atributos e às operações das
classes, por outros classificadores:
• Classificadores são: casos de uso, classes, objetos,
interfaces, componentes e nós
+ público: qualquer objeto externo pode acessar
# protegido: somente os descendentes pode acessar
‒ privado: somente a própria classe pode acessar (default)
Retângulo
‒ coordsP1
‒ coordsP2
+ mover()
# aumentar()
# diminuir()
‒ calcularArea()
Prof. Welton Duque
Objetos são instâncias de classes
Classe Tipo de dado
Nome da Classe Tarifa
Tarifa
Table precosRegioes
precosRegioes Atributos Enumeration getRegioes()
getRegioes() Price getPrecos(Zone)
getPrecos() Operações
Assinatura Assinatura
Tarifacao::Tarifa
Tarifa
Nome do Pacote
Nome do Objeto Nome da Classe Nome do Objeto
(uma instância da Classe) Objeto anônimo (sempre sublinhado)
tarifas2017:Tarifa :Tarifa tar2018:Tarifa

precosRegioes={ precosRegioes={ precosRegioes={
{‘1’, 2.50}, {‘1’, 2.50}, {‘1’, 3.80},
{‘2’, 3.25}, {‘2’, 3.25}, {‘2’, 4.90},
{‘3’, 5.60}} {‘3’, 5.60}} {‘3’, 8.15}}
Valores do objeto Valores do objeto

Prof. Welton Duque
Atores x Classes x Objetos
ATOR
• É uma entidade externa ao sistema, identificada durante a
modelagem dos Casos de Uso
• Normalmente, existirá uma Classe modelada para cada
tipo de Ator (papel) que interage com o sistema
CLASSE
• É uma abstração que modela uma entidade interna ou
externa do sistema, pertencente ao domínio da aplicação
• Uma classe define dados estáticos e comportamentos
OBJETO
• É uma instância específica de uma classe específica
• Logo, uma aplicação possuirá vários objetos que
representam tanto as entidades externas quanto as
entidades internas, do sistema
Prof. Welton Duque
Responsabilidades das Classes
• Uma responsabilidade delimita um conjunto de obrigações
(contrato) a serem cumpridas por uma determinada classe
• Os atributos e operações de uma classe representam as
características dinâmicas e estáticas de como a classe
cumpre as suas responsabilidades (obrigações)
• Ao modelar uma classe, um bom ponto de partida é,
primeiro, especificar todas as suas responsabilidades
• Os Casos de Uso são a fonte principal de informações para
a identificação das responsabilidades do sistema
• A modelagem de classes distribui as responsabilidades do
sistema (isso define a semântica das classes)
• Na prática, toda classe tem pelo menos uma
responsabilidade bem específica, somada a um conjunto
adicional de outras responsabilidades
Prof. Welton Duque
Responsabilidades das Classes
• As responsabilidades podem ser graficamente escritas no final do
desenho da classe, dentro de um compartimento
• São escritas em texto livre, podendo ser uma expressão, uma oração
ou um parágrafo curto
• A distribuição de responsabilidades deve ser feita de forma
equilibrada, para que não haja classes:
– com muitas responsabilidades: dificulta a manutenção e o reuso
do software e modelos criados (poucas classes, muito pesadas)
– ou com poucas responsabilidades: dificulta o gerenciamento e a
compreensão das abstrações (muitas classes pulverizadas)
AgenteDeFraude Nome da Classe
Responsabilidades
Atributos
- Determinar o risco do pedido de um Operações
cliente
- Tratar os critérios de fraude Responsabilidades
específicos do cliente
- Registrar e notificar as fraudes
Prof. Welton Duque
Identificação de responsabilidades de Classes
• Quando tiver identificado uma responsabilidade,
pergunte-se a que classe ela pertence
• Pergunte-se a si mesmo(as) quais são os
conhecimentos que a classe possui (informações e
operações)
• Indague a si mesmo(a) o que a classe faz, ou seja,
quais funcionalidades estão associadas a ela
• Algumas vezes, nós identificamos responsabilidades
que não precisam ser implementadas
• As classes precisam colaborar, a fim de
desempenharem as suas responsabilidades
Prof. Welton Duque
Dicas para a identificação de Classes
• As Classes não existem sozinhas e um sistema só funciona
por meio da colaboração conjunta de várias classes
• Os objetos dependem de outros objetos para realizarem as
suas atividades e cumprirem suas responsabilidades
• Tudo aquilo que interaja ou faça parte do sistema é uma
classe: pessoas, lugares, objetos, eventos, conceitos, telas,
relatórios, etc.
• Todo cliente de um sistema é uma classe: aluno, professor,
comprador, cliente bancário, passageiros, etc.
• Siga o fluxo do dinheiro: pergunte-se de onde ele vem,
como é arrecadado e como é gasto, para descobrir as
classes de clientes, produtos, serviços e suporte
Prof. Welton Duque
• Um relatório é uma classe: qualquer relatório gerado por
um sistema é uma classe que requisita informações de
outras classes, processam informações e geram resultados
• Uma tela é uma classe: cada tela de interface entre os
usuários e o sistema deve ser modelada como uma classe
• Um sistema geralmente possui entre 3 e 5 classes
principais (representação o core business):
– Sistema de vendas de passagens: Passageiro, Vôo, Tripulação,
Aeroporto, Avião
– Sistema de gestão de faculdades: Aluno, Professor, Curso,
Disciplina, Sala de Aula
• Utilize um ou dois substantivos, no máximo, no singular,
para definir o nome de uma classe: TelaDeCadastro, Aluno,
SalaDeAula, TelaAtribuicaoNotas, BoletimAluno, etc.
Prof. Welton Duque
• Existem quatro tipos de classes usuais: Atores, Interfaces,
Relatórios e Negócios.
• Atores: são pessoas e sistemas externos, presentes no
mundo real, que interagem com o sistema modelado
– Exemplo: Professor, Aluno, etc.
• Negócios: são lugares, objetos, produtos, conceitos,
eventos que fazem parte da natureza do negócio
– Exemplo: Sala de Aula, Boletim, Disciplina, Curso, Evento
• Interface: são as telas e menus que compõem a interface
do sistema
– Exemplo: TelaLançamento Notas, TelasDownloadMateriais, etc.
• Relatórios: representam todos os relatórios emitidos pelo
sistema (atividades: obter, processar e imprimir dados)
– Exemplo: Lista de Cursos Matriculados
Prof. Welton Duque
Exemplo: Classes de um sistema de vendas
Atores::Cliente Pedido Produto Entrega
idCliente idPedido idProduto
nomeCliente item nome
endereçoCliente quantidade preçoUnitário Responsabilidades
telefoneCliente idDeposito -- manter as informações
referentes aos produtos entregues
de um pedido (histórico)
Fatura -- acompanhar o status da
idCliente AgenteContasReceber localização dos produtos entregues
pedidos (rastreamento dos pedidos)
Responsabilidades
-- Controlar a solicitação dos
pedidos
Robô
Depósito id
idDeposito localização
localização tipo Transação
idProduto processarPedido() ações
quantidade alterarPedido() confirmar()
status() reverter()
Responsabilidades Responsabilidades foiBemSucedida()
-- Manter informações do -- Empacotamento Responsabilidades
local de armazenamento dos produtos no -- Coordenar as alocações de frete
dos produtos depósito dos pedidos
Prof. Welton Duque
Exemplo: Classes de um sistema Escolar
Aluno TurmaSemestre
matriculaAluno nomeDaTurma
nomeAluno nomeTurmaGerencial
endereçoAluno numeroDeAlunosMatriculados
salaDeAulaPadrao
emailAluno tipoOferta
matricularNaDisciplina unidadeOferta
entregarTrabalho anoSemestre
verificarNotas matricularAluno
solicitarHistoricoEscolar excluirAluno
matricularSeEmSeminario obterListaNomesAlunos
obterListaNomesProfessores
Disciplina obterListaNomesDisciplinas
codigoDisciplina
nomeDisciplina Professor
cargaHorariaDisciplina idProfessor
salaAulaDisciplina nomeProfessor
numAlunosMatriculados titulacaoAcademica
notasAlunos areaDeFormacao
obterNumeroVagasDisponiveis disponibilidadeHorasSemanais
obterPrerrequisitos associarDisciplina
adicionarRemoverAluno listarDisciplinasQueLeciona
obterListaAlunos
agendarDataAvaliacao listarDisciplinasLecionando
obterMediaAvaliacoes lancarNotasPortal
Prof. Welton Duque
Relacionamentos entre Classes
• As Classes não existem sozinhas e um sistema só
funciona por meio da Colaboração conjunta de
várias classes
• Para colaborarem, elas se associam de diferentes
formas:
– Dependência
Estes são os quatro
– Associação relacionamentos mais
– Generalização importantes da modelagem
Orientada a Objetos
– Realização
– Agregação Casos específicos do
relacionamento de
– Composição Associação
Relacionamentos entre Classes ii.54
Prof. Welton Duque
Associação Operadores de multiplicidades
• Relacionamento estrutural para (ou cardinalidades):
indicar que os objetos de uma classe * zero ou muitos
estão conectados aos objetos de 0..* zero ou muitos
outra classe 1..* Um ou muitos
• Permite a navegação entre objetos de 1 exatamente um
diferentes classes e até entre os 0..1 Zero ou um
objetos da mesma classe 2..5 Entre dois e cinco
• Representada por uma linha cheia, 3 apenas três
com a indicação de nome (opcional) e 1..4, 6..* um ou vários,
multiplicidade do relacionamento exceto 5
(branco) 1 se não for
especificado
associação associação
Prof. Welton Duque
Multiplicidade e Navegação das Associações
MULTIPLICIDADE:
• Define quantos objetos participam do relacionamento
• Número de instâncias (objetos) de uma classe, que está(ão)
relacionada(s) à(s) instância(s) de outra classe
• É especificada em cada uma das pontas da associação
NAVEGAÇÃO:
• Por default, as associações, agregações e composições são
bidirecionais (os dois objetos são acessíveis entre eles)
• Entretanto, poderá haver associações unidirecionais, em
que a seta indica a única opção permitida de acesso
Prof. Welton Duque
Associação
• As associações entre os objetos (instâncias) são mapeadas
pelos atributos de suas respectivas classes
• As associações "muitos" para "muitos" exigem a criação e
o correto controle de tabelas denominadas "agregados",
dentro dos bancos de dados relacionais
Diagramas de Classe: associação
ArquivoAula * * Turma
arquivoAulaID está associado a
turmaID
public class ArquivoAula

{
public int arquivoAulaID;
private Vector m_turmasAssociada = new Vector();
Java: };
public class Turma
{
public int turmaID;
private Vector m_arquivosAulaAssociados = new Vector();
};
Prof. Welton Duque
Associação
Na classe abaixo, temos:
• Associação com rótulo e papéis
• Rótulo: "hierarquia"
• Papéis: "subordinado" e "chefe"
• Todo subordinado e todo chefe é um empregado
• Um chefe tem 1 ou mais subordinados
Prof. Welton Duque
Agregação
• Representada por uma linha com um losango na ponta, no
lado da classe que representa o "todo"
• Caso especial de associação entre duas classes, denotando
um relacionamento do tipo “é parte de” ou "tem um", em
que uma das classes representa um item maior ("o todo")
e a outra representa "a parte"
• No sistema real, o relacionamento se dá por meio dos
objetos instanciados de suas classes
• A agregação não altera a navegação entre os objetos
• No exemplo abaixo: Toda Empresa tem Departamento (em
quantidade zero, um, dois, vários, etc.)
Todo Parte
agregação
Prof. Welton Duque
Composição
• É uma associação, com um losango cheio na classe que
representa "o todo"; seu relacionamento com as partes é
mais forte que o da agregação
• Os objetos "partes" podem ser criados após o objeto
"todo", mas morrem quando o objeto "todo" é encerrado
• O objeto do "todo" (composto) deve gerenciar a criação
(instância) e a destruição (liberação) dos objetos partes
Todo Parte
composição
associação
associação
agregação
Parte
Prof. Welton Duque
Composição
• Um Empregado trabalha para apenas uma Empresa e, se a empresa
for destruída, o empregado também o será
• Empresa e EquipeDeProjeto mantêm uma relação de composição
em que seguem as mesmas restrições entre empresa e empregado
• Um Empregado pode fazer parte de

mais de uma EquipeDeProjeto e a
extinção de uma EquipeDeProjeto não
implica na destruição do empregado
• Portanto, a relação entre
EquipeDeProjeto e Empregado não
pode ser considerada uma composição
Prof. Welton Duque
Dependência
• Linha tracejada com uma seta aberta na ponta
• É um relacionamento mais fraco que a associação
• Relacionamento de utilização (não estrutural), em que a
mudança na de um item pode afetar o item dependente
• Pode ser usada entre classes, objetos, casos de uso,
pacotes e componentes
dependência
✓ A classe AgendaDeCursos depende da

classe Curso
✓ A classe Curso não conhece a existência da
dependência classe AgendaDeCursos
✓ Alterações na classe Curso podem afetar o
comportamento de AgendaDeCursos
✓ Iterador depende da AgendaDeCursos
Prof. Welton Duque
Dependência
• Na prática, as dependências ocorrem:
nos parâmetros de entrada das operações
nos tipos de retorno das operações
na utilização de objetos dentro do código das operações
nas exceções lançadas
• É possível estabelecer relações de dependência entre
diferentes elementos estruturais (estáticos) da UML:
Classes Cliente Fornecedor
Pacotes Componentes
dependência
PacoteCliente PacoteFornecedor Cliente Fornecedor
dependência dependência
Prof. Welton Duque
Generalização
• Linha cheia com seta branca na extremidade, apontando
para a classe superior (ou caso de uso, ator, etc.)
• Denota um relacionamento "é-um-tipo-de":
– Um avião "é-um-tipo-de" transporte
– Um dragão é um tipo de pássaro e um tipo de réptil
• A classe filha herda as características da classe mãe
• Os objetos da classe-filha podem ser usados em qualquer
local em que a classe-mãe ocorra, mas não o contrário
• Polimorfismo: prevalece a operação da filha que tenha a
mesma assinatura da operação da mãe
• Classe-raiz: é uma classe que não possui classe mãe
• Classe-folha: é uma classe que não possui classes-filhas
• Herança simples: a classe filha tem apenas uma mãe
• Herança múltipla: classe filha que tem mais de uma mãe
Prof. Welton Duque
Generalização
HERANÇA SIMPLES
generalização
associação
generalização
dependência
Prof. Welton Duque
Generalização
HERANÇA MÚLTIPLA
Prof. Welton Duque
Generalização
HERANÇA MÚLTIPLA
HERANÇA SIMPLES
Prof. Welton Duque
Generalização
HERANÇAS
SIMPLES E
MÚLTIPLAS
Prof. Welton Duque
✓ Alunos e Coordenações são partes da Escola (agregação)
✓ As Coordenações só existem enquanto a Escola existir (composição)
✓ A DisciplinaEAD herda os atributos e operações da classe Disciplina
✓ Os demais relacionamentos entre as classes são todos de associações
✓ As multiplicidades devem ser todas indicadas nas associações entre classes
Todo Parte
Parte
Diagrama de Classes
Sistema de Consultório Dentário ii.69
Prof. Welton Duque
Prof. Welton Duque
Interfaces
• A interface é um conjunto de operações (serviço) que uma
classe ou item está obrigado a realizar (é um contrato!)
• A interface define "o quê" fazer (conjunto de assinaturas
das operações), mas não define "como" fazer as operações
• Esta é a vantagem da interface, pois toda a implementação
("como") está separada da especificação ("o quê")
• Uma interface pode incluir apenas uma parte ou todo o
comportamento (operações) de uma classe ou item
realização dependência
Publicador é uma interface Aqui, a interface Publicador

fornecida pela Classe1, ao está sendo requerida pela
mundo externo. É a Classe1 Classe2, que apenas a
que define esta interface. requer, mas não a define.
Prof. Welton Duque
Interfaces
• Uma interface tem um nome e contém apenas assinaturas
de operações abstratas e constantes
• Um interface não pode ser instanciada, mas pode ser
implementada por uma ou mais classes
• Em Java, uma classe pode herdar de apenas uma única
classe (ou seja, não existe herança múltipla em Java)
• Mas, uma classe Java pode requerer diversas interfaces e
este é o mecanismo que o Java usa para a herança múltipla
• Uma interface é declarada como uma classe, usando o
estereótipo <<interface>> acima do seu nome de classe
• Graficamente, pode ser representada pela classe
estereotipada ou por um pequeno círculo e linha (pirulito)
• Um classe que implementa uma interface deve
implementar todos os métodos da interface, ou seja, não
pode deixar nenhum método sem implementação
Prof. Welton Duque
Realização
• Linha pontilhada com um triângulo aberto, apontado para
o item que representa o contrato a ser executado
• Usado entre interfaces e classes que as realizam; ou entre
casos de uso e colaborações que os realizem (casos de uso)
• Interface: conjunto de operações que especificam o
contrato de uma classe, separadas de sua implementação
Forma
canônica
Classe Classe
Forma Icônica
Interface
Componente
Forma
canônica
Caso de Uso Colaboração
Relacionamentos entre Classes
Interfaces
ii.73
Prof. Welton Duque
Realização
Interface
(por meio de Interfaces)

Prof. Welton Duque
Nome de um papel
da classe Funcionário
Como você modelaria? ii.75
Prof. Welton Duque
Associação, Agregação, Composição, Dependência,
Generalização, Realização
• Dependente e Funcionário?
• Família e Filhos?
• Pedido e Item de pedido?
• Funcionário e Cartão de Ponto?
• Carro, Roda, Direção e Motor?
• Curso, Curso de Graduação e Disciplinas?
• Aluno, Disciplina, Avaliação, Prova e Trabalho?
• Pessoa, Aluno, Crença, Religião, Oração?
• Funcionário, Empresa, Cargo, Salário, Setor?
• Conta bancária, cartão, outras contas, gerente?
Prof. Welton Duque
Passos da Modelagem Orientada a Objetos
1. A partir do problema e das tecnologias disponíveis,
defina todo o vocabulário possível do sistema, listando
os itens que os usuários e desenvolvedores citam para
descrever o problema ou a solução...
2. A partir do vocabulário, defina as abstrações...
3. A partir das abstrações, defina as responsabilidades...
4. A partir das responsabilidades, defina as classes...
5. A partir das classes, defina seus atributos e operações...
6. Depois, defina seus relacionamentos (estáticos) e as
colaborações (trocas de mensagens) entre seus objetos...
7. Por fim, implemente, teste e ponha o sistema em uso!
8. GO-LIVE !!!
Notas de comentários em UML ii.77
• Existe uma representação gráfica para comentários
Prof. Welton Duque
em UML chamada nota

• As notas são usadas para especificar requisitos,
observações, revisões, explanações, restrições, etc.
• Uma nota pode conter textos e imagens juntos,
URL, links para documentos, etc.
nota
ii.78
Prof. Welton Duque
Diagrama de Objetos
Diagrama de Objetos ii.79
Prof. Welton Duque
• O diagrama de objetos modela instâncias reais de

itens que estão presentes no diagrama de classes
• Mostra os objetos, suas conexões e valores de seus
atributos, em um dado ponto no tempo (estado)
– Exemplo: Metáfora do Futebol Americano
• São úteis para a modelagem de estruturas de dados
complexas (um objeto + relações com obj. vizinhos)
• As falhas em sistemas orientados a objetos são
caracterizadas por conexões interrompidas entre
objetos ou por atributos com valores danificados
welton :
: Professor welton :
Professor
Apenas o nome da Nome da classe Apenas o nome do
classe (objeto anônimo) e do objeto objeto
Prof. Welton Duque
• Um sistema em execução pode conter de centenas

a milhares de objetos, a maioria deles anônimos
• O diagrama de objetos mostra apenas uma parte
destes objetos (não é necessário mostrar todos)
• Não mostra a evolução do sistema com o tempo; o
diagrama representa apenas um ponto no tempo
• Multiobjects: conjuntos de objetos (quantidade
indeterminada) usados em diagramas de
colaboração
welton
: Curso
Fulano :
Pier: Professor codCurso: "ECO0137"
Korea: Aluno descrição: "MODELP"
: Aluno codTurma: "GEC-5/6-0137NA"
Prof. Welton Duque
Diagrama de Classes
Diagrama de Objetos
Prof. Welton Duque
Diagrama de Classes
Diagrama de Objetos
Multiobjects
Diagrama de Objetos Prof. Welton Duque
ii.83
Curso Aluno
Diagrama de Classes Professor
ministra -codDisciplina: String -matrícula: String
-matrícula: String
1..3 1..5 -descrição: String 0..10
*
-nome: String
-nome: String
-codTurma: String -período: Integer
Diagrama de Objetos
p1: Professor
p2: Professor
matricula: "205-6712-09"
nome: "Jaelson Castro"
c1: Curso c3: Curso
: Curso c2: Curso

: Curso
codCurso: "IF291"
codCurso: "IF185"
descrição: "MPS" : Aluno
descrição: "AER" : Aluno
codTurma: I7
codTurma: I6
: Aluno
: Aluno : Aluno :aluno

Bill Uncle Bean
matricula: "219846534"
:aluno nome: "Nelson Mandella"
: Aluno
matricula: "562746134"
nome: "John Major"
ii.84
Prof. Welton Duque
Diagramas de Interação
Diagramas de Interação ii.85
Prof. Welton Duque
• Modelam as interações entre o sistema e os seus

atores (conforme os casos de uso)
• A interação é iniciada por um ator, que interage
com instâncias (objetos) das classes do sistema
• Um ator também possui a sua instância de classe
• Os diagramas de interação capturam a semântica
(lógica) do fluxo de eventos de cada caso de uso
• Quando modelados dentro dos casos de uso (antes
da modelagem de classes), ajudam a identificar as
classes, responsabilidades e seus relacionamentos
• Quando criados depois da modelagem das classes,
servem para refinar os comportamentos e trocas
de mensagens entre os objetos
Diagramas de Interação ii.86
Prof. Welton Duque
• Existem dois tipos de diagrama de interação:

❖ Diagrama de Sequência
❖ Diagrama de Comunicação (antigo Colaboração)
• Ambos são semanticamente equivalentes, mas têm
representações gráficas diferentes para
representar um mesmo comportamento do sistema
• Por terem semânticas iguais, um pode ser gerado a
partir do outro e vice-versa
• Comunicação: visualizar os relacionamentos
estruturais entre os objetos; mais fáceis de
desenhar e mais úteis em sessões de brainstorming
• Sequência: melhores para visualizar a sequência
dos fluxos no tempo, mostram os fluxos completos
e são mais adequados para cenários complexos
ii.87
Prof. Welton Duque
Diagrama de Sequência
Diagrama de Sequência ii.88
• Mostra a sequência dos fluxos no tempo, de troca
Prof. Welton Duque
de mensagens entre os objetos, em um cenário

Este é um programa
CGI ou ISAPI
Processador de Interface com

Browser Servidor Web
pedidos o banco
Estudante
Submeter formulário
de pedido preenchido
Codificar dados
do formulário
Enviar dados
codificados Processar dados
Executar
Enviar dados
processados
Cadastrar pedido
Cadastro OK
Gerar página
de confirmação
Enviar página
Enviar página
Exibir página
Prof. Welton Duque
• O diagrama de sequência enfatiza a ordenação

temporal das mensagens trocadas entre os objetos
• Um cenário é uma sequência específica de ações,
que ilustra um comportamento de um caso de uso
• Os casos de uso são a base para o desenvolvimento
dos diagramas de sequência
• Diagramas de Sequência podem mostrar estruturas
de decisão (if-then) e de repetição (loop)
• Um objeto pode enviar mensagens a outro objeto;
que, por sua vez, pode enviar outras mensagens a
outros objetos, e assim por diante, formando uma
sequência de mensagens (como uma colaboração)
• Na maioria das vezes, uma mensagem resulta na
execução de uma operação pelo objeto receptor
Prof. Welton Duque
Mensagens
• Uma mensagem define uma comunicação entre
objetos, que contém informações sobre as quais
existe uma expectativa de resultado (e retorno)
• A ação da mensagem ocorre no objeto destinatário
e poderá resultar em mudanças de estado deste e
de outros objetos vinculados e acessíveis por ele
• Tipos básicos de mensagens na UML:
❖ Call: invoca uma operação a um objeto solicitado
❖ Return: retorno de valor ao objeto solicitante
❖ Send: envio de um um sinal para um objeto
❖ Create: criação (instanciamento) de um objeto
❖ Destroy: destruição de um objeto
Prof. Welton Duque
Mensagens
• Os objetos interagem por meio da troca de
mensagens
• Sintaxe:
Fonte: Laboratório de Engenharia de Software (PUC-RJ)

Prof. Welton Duque

Tipos de numeração das mensagens (a numeração é opcional):
Diagrama de Sequência 1) Sequencial: 1, 2, 3, 4, 5, 6, ....
2) Aninhada: 1, 2, 2.1, 2.2, 3, 3.1, 4, ....
ii.93
Prof. Welton Duque

Prof. Welton Duque
• As mensagens podem apresentar condições lógicas

de envio, chamadas condições de guarda:
– Sintaxe: [condição de guarda] mensagem()

Prof. Welton Duque
• Uma mensagem pode ser enviada repetidas vezes
– Sintaxe: * [condição de loop] mensagem()
– Exemplo: * [i=1..5] //executa a mensagem 5 vezes
– * [resp=false] //executa enquanto resp=false

Prof. Welton Duque
Prof. Welton Duque
Chamada Telefônica ii.98
Prof. Welton Duque
• Mostra a sequência dos fluxos no tempo, de troca Prof. Welton Duque
de mensagens entre os objetos, em um cenário

Janela de entrada
p: Pedido : ItemPedido :ItemEstoque
de pedido
preparar()
* [para cada item do pedido]

preparar()
emEstoque := verificar()
[emEstoque]
remover() estoqueBaixo :=
verificEstoqueBaixo()
[estoqueBaixo]
<<crieate>
:ItemRenovEstoque
[emEstoque]
<<create>>
:ItemEntrega
Diagrama de Comunicação ii.100
• Mostra os relacionamentos estruturais entre os
Prof. Welton Duque
objetos que participam de um cenário definido

Janela de entrada
de pedido
1: preparar()
p: Pedido
1.1: *[para cada item do pedido]

preparar() 1.1.2.1: estoqueBaixo :=
verificEstoqueBaixo()
1.1.1 : emEstoque := verificar()

1.1.2 : [emEstoque] remover()
: ItemPedido :ItemEstoque
1.1.3 : [emEstoque] 1.1.2.2 [estoqueBaixo]

<<criar>> <<criar>>
:ItemRenovEstoque
:ItemEntrega
Prof. Welton Duque
Passo-a-passo de modelagem
1. Definir o contexto do diagrama: o sistema inteiro,
um subsistema, uma operação, uma classe, um
caso de uso ou uma colaboração de casos de uso
2. Identificar os objetos que participam da interação
e distribua-os da esquerda para a direita, deixando
os mais importantes à esquerda
3. Identificar o objeto que inicia a interação
4. Define linha de vida dos objetos (create/destroy)
5. Identificar as mensagens trocadas entre os objetos
que participam da interação
6. Identificar a sequência destas mensagens
7. Garantir que todos os parâmetros de envio e de
retorno estejam corretamente modelados
ii.102
Prof. Welton Duque
Diagrama de Atividades
Diagrama de Atividades ii.103
• Implementa a mesma ideia dos já conhecidos Prof. Welton Duque
fluxogramas, destacando o fluxo das atividades

envolvidas na realização de uma tarefa
• É usado para modelar atividades concorrentes e
ramificações de fluxos
• Faz o uso de barras de sincronização (forks e joins)
para especificar a concorrência entre atividades
• Um fork (garfo em inglês) representa um único
fluxo que se divide em vários fluxos concorrentes
• Depois de um fork, as atividades são realizadas em
qualquer ordem ou simultaneamente
• Um join representa a sincronização de dois ou mais
fluxos de controle concorrentes, em um único fluxo
• Um join só pode ser realizado após todas as
atividades, que nele se juntam, estarem concluídas
Diagrama de Atividades Pessoa
[sem café] [sem Coca]
ii.104
Prof. Welton Duque
H Procurar bebida
inicialização [achou café] ramificação

fork [achou Coca]
(podem usar
um "[else]")
Colocar café Adicionar água à Pegar
no filtro máquina xícara Pegar lata
de Coca fluxos
de controle
Colocar filtro
na máquina
join
Ligar máquina
Filtrar café
join
término
Colocar café na
Beber H
xícara
Prof. Welton Duque
• Faz a modelagem das atividades sequenciais de um

processo computacional (comportamento)
• O diagrama de interação enfatiza os fluxos de
controle entre objetos
• O diagrama de atividade dá ênfase aos fluxos de
controle entre ações (computações) do sistema
• Uma atividade é uma execução estruturada de um
comportamento decomposto em ações individuais
• Ações são computações executáveis, atômicas, que
resultam em mudanças de estados do sistema
• As ações provocam retornos de valores, alteram
atributos e invocam operações entre os objetos
• Os fluxos de controle das ações são representados
por setas com flechas abertas na ponta
Prof. Welton Duque
Swimlanes ("raias de natação" em inglês)
• Swimlanes: usadas para Cliente Vendas Estoque
definir organizações de
H
negócio responsáveis pela Solicitar pr oduto
organizações
de negócio são
realização de ações que entidades do
possuem propriedades mundo real
organizacionais comuns Proce s sar pe dido
Cole tar m ate r iais
• As swimlanes modelam os
fluxos de trabalho dos Enviar pe dido
processos de negócio
empresariais (empregam a
notação BPMBN) Re cebe r pe dido Cobrar do clie nte
• Cada swimlane representa

uma responsabilidade de
alto nível, implementada Pagar conta
Ence r rar pe dido
por uma ou mais classes

do sistema H
Prof. Welton Duque
Prof. Welton Duque
Swimlanes (raias)
Prof. Welton Duque
Passo-a-passo de modelagem
1. Um diagrama de atividades pode representar um sistema
por um todo, ou um subsistema, ou uma classe ou uma
operação específica
2. Também pode representar um caso de uso ou uma
colaboração de casos de uso (sociedade de objetos)
3. Quando modelam uma operação, são fluxogramas
detalhados, com joins, forks e ramificações, envolvendo o
envio e recebimento de parâmetros entre os objetos
4. Quando modelam um fluxo de trabalho, são fluxos de
nível mais alto, que representam um processo de negócio
5. Estabeleça um foco para cada fluxo de trabalho ou
operação, pois é impossível mostrar todos os fluxos de um
sistema em um único diagrama de atividades
6. As operações contendo comportamentos complexos são
ideais para a modelagem de um diagrama de atividades
ii.110
Prof. Welton Duque
Diagrama de Estados
Diagrama de Estados ii.111
Prof. Welton Duque
• Um diagrama de estados mostra os possíveis estados de
um objeto individual, incluindo os eventos e operações
responsáveis pelas mudanças desses estados
• Um conjunto de estados e transições de um objeto
representa uma máquina de estados, que modela o
comportamento e o ciclo de vida de cada objeto, desde a
sua criação até a sua extinção
Prof. Welton Duque
• A máquina de estados modela o tempo de vida de um
objeto, de um caso de uso ou de um sistema inteiro
• Máquinas de estados estruturadas são como algoritmos
bem-estruturados: eficientes, simples, adaptáveis e
compreensíveis
Prof. Welton Duque
• Eventos causam mudanças (transições) de estados dos
objetos, em resposta às operações que estes recebem
• Um evento representa uma ocorrência significativa, que
tem uma localização no tempo e no espaço
• Uma transição é um relacionamento entre dois estados
Prof. Welton Duque
• O comportamento de objetos que precisam responder a
mensagens assíncronas, ou cujo comportamento atual
depende de seus estados passados, é melhor representado
por meio de uma máquina de estados
• Um estado é o momento específico da vida de um objeto,
durante o qual o objeto satisfaz uma condição, realiza
uma atividade ou aguarda um evento
Prof. Welton Duque
• O diagrama de estados também mostra as respostas a

estes eventos, em função do estado atual
• Os nomes dos estados típicos de um sistema podem ser
verbos no gerúndio, verbos no particípio ou substantivos
verbais:
➢ Aguardando (verbo no gerúndio)
➢ Processado (verbo no particípio)
➢ Manutenção (substantivo verbal)
➢ Validando (verbo no gerúndio)
➢ Parado (verbo no particípio)
➢ Ativo (substantivo verbal)
Prof. Welton Duque
Elementos do diagrama de estados
nome do diagrama evento condição
de guarda estado
estado inicial evento(trigger)
condição efeito transição
transição de
auto-transição conclusão
evento de entrada
enquanto está no estado
evento de saída
ação resposta
estado transição interna
condição estado final
ii.117
Prof. Welton Duque
Diagrama de Componentes
Diagrama de Componentes ii.118
Prof. Welton Duque
• Componentes são partes modulares de um
sistema, que ocultam a sua implementação por
meio de interfaces
• São graficamente representados por um retângulo,
com um ícone especial no canto superior direito
• Eles existem no mundo material:
Um item em tempo de execução (bibliotecas, docs, etc.)
Um arquivo de código fonte (.c, .vbs, .java, .frm, etc.)
Um arquivo executável (.exe, .dll, .class, etc.)
Uma tabela ou arquivo de um banco de dados
• Um componente que implementa um certo conjunto
Prof. Welton Duque
interfaces pode ser substituído por outro componente que

apresente as mesmas interfaces
• Por isso, os componentes são partes substituíveis e "quase
independentes" de um sistema
• Eles indicam módulos de hardware e software e são usados
para modelar a arquitetura física do sistema
• Seus relacionamentos são sempre de dependências que
apontam para interfaces
Prof. Welton Duque
Format.dll
JanelasComuns.dll
Palavras.exe
Palavras.ini
Palavras.hlp
Ortograf.dll
Prof. Welton Duque
Cadastro.exe
<<link>>
Usuários
FormCadastro.html
Banco
<<link>>
Autenticacao.exe
Senhas
Principal.html
FormEntrada.html
ii.122
Prof. Welton Duque
Diagrama de Pacotes
Diagrama de Pacotes ii.123
Prof. Welton Duque
• Pacotes são itens de agrupamento conceitual, usados para
organizar e facilitar a legibilidade dos modelos UML
• As classes organizam responsabilidades e os pacotes
organizam subsistemas, itens, estruturas, hardware,
elementos de software e outros itens da UML
• Existem apenas no tempo de desenvolvimento e favorecem
a modularidade do sistema
• Seu desenho gráfico é de uma pasta, com um nome:
ii.124
Prof. Welton Duque
Subsistemas
Subsistemas ii.125
• Um subsistema é uma combinação de pacotes (contém Prof. Welton Duque
itens estáticos, elementos) e classes (têm comportamento)

• Um subsistema realiza uma ou mais interfaces, que
definem o seu comportamento total
• Facilitam o encapsulamento e a modularidade de software
• Encapsulamento: o acesso aos atributos de uma classe
deve ser feito somente pelos métodos da classe e não
diretamente por outra classe
• Sua notação gráfica é parecida com a do pacote, porém,
acrescenta um símbolo no retângulo superior e o
estereótipo de <<subsistema>> acima do seu nome
subsistema estereótipo
realização
interface nome do subsistema
Subsistemas ii.126
Prof. Welton Duque
• Componentes e subsistemas encapsulam comportamento
modelos por meio de interfaces
• Um componente representa uma parte modular de um
sistema (item executável, código fonte, etc.)
• Um subsistema representa um componente do modelo de
projeto
• Logo, componentes são a realização física dos subsistemas,
cujas especificações de ambos são feitas por interfaces
subsistema
interfaces
componente
ii.127
Prof. Welton Duque
Diagrama de Implantação
Diagrama de Implantação ii.128
Prof. Welton Duque
• Os diagramas de implantação são usados para

modelar o ambiente e a arquitetura de distribuição
em que o sistema será executado (topologia)
• São compostos por nós e relacionamentos de
comunicação
• Só fazem sentido para sistemas que rodam em
várias máquinas e dispositivos
• Um nó pode ser um computador, uma rede, um
disco rígido, um sensor, etc.
• Os nós representam elementos físicos (tangíveis) e
são os elementos mais estereotipados da UML
• Símbolos como PCs, workstations, servidores e
dispositivos são muito usados nos diagramas de
implantação
Prof. Welton Duque
• Um nó é um elemento físico que existe em tempo

de execução e representa um recurso
computacional
• Um nó geralmente possui memória e capacidade de
processamento
• Uma associação entre dois nós representa uma
conexão física entre eles, como: uma conexão
ethernet, WIFI, link de satélite, etc.
Prof. Welton Duque
PC
Google
Chrome
Principal.html
servidorWeb
FormCadastro.html
Autenticação.exe
servidorDeArquivos
Cadastro.exe
FormEntrada.html
O SGBD a ser
servidorBancoDeDados utilizado ainda
não foi escolhido.
SGBD
ii.131
Prof. Welton Duque
Mecanismos adicionais
da UML
Mecanismos ii.132
Prof. Welton Duque
• Uma única forma ou linguagem fechada jamais será

capaz de expressar todas as nuances possíveis de
um modelo
• Por isso, a UML permite a ampliação controla de
sua linguagem, por meio de mecanismos de
extensibilidade
• Podem ser usados para estender elementos atuais
da UML, permitindo a definição de novos
elementos, a partir das notações gráficas de
elementos existentes
• Dentre alguns mecanismos, tem-se:
 Estereótipos
 Notas
 Propriedades (Tagged values)
 Restrições
Estereótipos ii.133
Prof. Welton Duque
• Usados para estender os elementos da UML

• Definem um novo modelo de elemento em termos
de outro já existente
• Pode ser aplicado a todos os elementos
• Podem ser representados por:
 Um novo ícone (notação gráfica, desenho)
 Ou palavra <<novo_elemento>> em um desenho atual
<<boundary>>
ClasseFronteira
ClasseFronteira
Notas ii.134
Prof. Welton Duque
• Anotação utilizada para adicionar informação aos

diagramas
• Pode ser vinculada a qualquer elemento de UML e
ligada por meio de uma linha tracejada
Esta classe é uma

abstração do dispositivo de
LeitoraCartao hardware que será usado
para ler efetivamente as
informações do cartão
magnético.
Propriedades (Tagged Values) ii.135
Prof. Welton Duque
• Servem para estender elementos da UML,

adicionando informações a eles
• Exemplos:
– Persistence
– Location (ex.: no cliente, no servidor)
• Novas propriedade podem ser criadas
Cliente LeitoraCartao
{persistence} {location=server}
Restrições ii.136
Prof. Welton Duque
• Usadas para a criação de novas regras ou
modificação de regras existentes sobre os
elementos do modelo
Funcionário
Professor 1..* 1 Departamento
{subset}
Coordenador
2 1
iii.137 Prof. Welton Duque
FIM
Muito obrigado a todos(as)!
Foi um prazer estar com vocês nesta
jornada de aprendizados e
compartilhamento de experiências!
Nos vemos em breve!
Sigamos em PAZ e HARMONIA!
E assertivos nas decisões futuras de nossas VIDAS.
Por favor, estudem e façam uma boa prova P2!
Prof. M.Sc. Eng. Welton Sthel Duque - 23/11/2017

MOD - 02 - Slides Aulas - Prof. Welton Duque

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

MOD - 02 - Slides Aulas - Prof. Welton Duque

Enviado por

Direitos autorais:

Formatos disponíveis

ii.

Prof. Eng⁰ Welton Sthel Duque

UML - Unified Modeling

Diagrama de Casos de Uso

• Os Atores são entidades do ambiente do sistema, podendo

Paciente Médico Secretária

A direção da seta indica o

Include: define que um

Os diversos casos de uso

o Nome o Fluxo Principal

<<include>>: define que um <<extends>>: significa que o caso

Manter Perfil Cliente

Conta Especial Conta Poupança

• As classes são os elementos mais importantes de um

• Toda classe tem um nome único e exclusivo, dentro

Nome da Classe (obrigatório)

mover() float mover(int x, int y)

tarifas2017:Tarifa :Tarifa tar2018:Tarifa

Valores do objeto Valores do objeto

public class ArquivoAula

• Um Empregado pode fazer parte de

✓ A classe AgendaDeCursos depende da

PacoteCliente PacoteFornecedor Cliente Fornecedor

Publicador é uma interface Aqui, a interface Publicador

(por meio de Interfaces)

em UML chamada nota

• O diagrama de objetos modela instâncias reais de

• Um sistema em execução pode conter de centenas

c1: Curso c3: Curso

: Curso c2: Curso

: Aluno : Aluno :aluno

• Modelam as interações entre o sistema e os seus

• Existem dois tipos de diagrama de interação:

de mensagens entre os objetos, em um cenário

Processador de Interface com

• O diagrama de sequência enfatiza a ordenação

Fonte: Laboratório de Engenharia de Software (PUC-RJ)

Fonte: Laboratório de Engenharia de Software (PUC-RJ)

Fonte: Laboratório de Engenharia de Software (PUC-RJ)

• As mensagens podem apresentar condições lógicas

Fonte: Laboratório de Engenharia de Software (PUC-RJ)

Fonte: Laboratório de Engenharia de Software (PUC-RJ)

de mensagens entre os objetos, em um cenário

* [para cada item do pedido]

objetos que participam de um cenário definido

1.1: *[para cada item do pedido]

1.1.1 : emEstoque := verificar()

1.1.3 : [emEstoque] 1.1.2.2 [estoqueBaixo]

fluxogramas, destacando o fluxo das atividades

inicialização [achou café] ramificação

• Faz a modelagem das atividades sequenciais de um

• Cada swimlane representa

por uma ou mais classes

• O diagrama de estados também mostra as respostas a

interfaces pode ser substituído por outro componente que

itens estáticos, elementos) e classes (têm comportamento)

• Os diagramas de implantação são usados para

• Um nó é um elemento físico que existe em tempo

• Uma única forma ou linguagem fechada jamais será

• Usados para estender os elementos da UML

• Anotação utilizada para adicionar informação aos

Esta classe é uma

• Servem para estender elementos da UML,