1. Prof: Rilmar Gomes
Copyleft2010 – Prof: Rilmar
Gomes<rilmargomes@hotmail.com>

2. Pressupõe que o mundo é composto por
objetos
Objeto é uma entidade que combina
estrutura de dados e comportamento
funcional
Os sistemas são modelados como um
número de objetos que interagem entre si
Em POO, temos que:
◦ Estrutura de dados + funções = objeto
◦ objeto + objeto + ... + objeto = programa
Copyleft2010 – Prof: Rilmar
Gomes<rilmargomes@hotmail.com>

3. Objetos são todas as coisas, reais ou
abstratas, às quais nossos conceitos se
aplicam.
Na OO estaremos interessados no
COMPORTAMENTO do Objeto.
Os objetos (computacionais) são compostos
ou representados por:
◦ ATRIBUTOS - Uma coleção de tipos de dados que
definem o ESTADO do Objeto.
◦ MÉTODOS - Ações ou procedimentos que alteram o
estado do objeto (Comportamento).
Copyleft2010 – Prof: Rilmar
Gomes<rilmargomes@hotmail.com>

4. Os atributos de um objeto definem as
qualidades e características da entidade que
ele representa
O estado de um objeto é o particular
conjunto de valores de seus atributos em um
dado momento
O comportamento de um objeto é definido
pelas alterações do seu estado em resposta a
mensagens que ele recebe (interação com
outros objetos)
Copyleft2010 – Prof: Rilmar
Gomes<rilmargomes@hotmail.com>

5. Objetos servem a dois propósitos:
◦ Facilitar a compreensão do mundo real,
◦ Fornecer uma base real para a implementação em
computador.
Os objetos possuem identidade e são
distinguíveis dentro de um Sistema
Copyleft2010 – Prof: Rilmar
Gomes<rilmargomes@hotmail.com>

6. Alguns exemplos de
Objetos:
◦ Um avião
◦ Uma Nota Fiscal
◦ Uma tela que o usuário
interage
◦ Um ícone numa tela
para qual o usuário
aponte e “abre”
◦ Uma árvore

7. Objetos podem ser compostos por outros objetos.
Isto permite que Objetos Complexos sejam definidos a
partir de objetos mais simples.

8. Para construir o objeto “carro”, teremos de
abstrair seus atributos e funções:
◦ um carro pode ter os seguintes recursos ou
atributos:
cor, velocidade máxima, tipo de combustível,
tamanho, modelo
◦ um carro pode:
andar, parar, virar à esquerda, virar à direita,
Copyleft2010 – Prof: Rilmar
Gomes<rilmargomes@hotmail.com>

9. Como descrever os objetos no mundo computacional?
◦ temos de mapear os objetos reais em objetos computacionais
e escrever programas que dão vida a estes objetos em um
sistema computacional.
◦ Para mapear os objetos (análise de um domínio) iremos utilizar
o processo de ABSTRAÇÃO.
Operação mental
para observar um
domínio e capturar Convenções
sua estrutura
ABSTRAÇÃO REPRESENTAÇÃO
Entidade Entidade
Observada Representada
Notação gráfica,
Carro
linguagem de programação

10. Diferentes abstrações a partir de um mesmo
objeto do mundo real
Cardinalidade
I, II, do conjunto
Maça
Peso
cor da casca
format
RECEITA
ATRIBUTO
3
CATEGORIA
AÇÃO

11. Focalizar o essencial, ignorar as propriedades
acidentais
AERONAVE

12. Surge a UML em 1996
como a melhor
candidata para ser a
linguagem unificadora
de notações.
Em 1997 a UML é
aprovada como padrão
pela OMG;
Desde então tem tido
grande aceitação

13. É independente de linguagem de
programação
É independente de processo de
desenvolvimento
Não é uma linguagem de programação
Não é uma metodologia
É uma linguagem visual

14. UML não guia um desenvolvedor em como
fazer análise e projeto
Não especifica o processo a ser seguido
Oferece uma notação para ser utilizada como
o desenvolvedor julgar necessário

15. Disponibiliza:
◦ Diagrama de Casos de Uso
◦ Diagrama de Classes
◦ Diagrama de Estados
◦ Diagrama de Atividades
◦ Diagrama de Seqüência
◦ Diagrama de Colaboração
◦ Diagrama de Componentes
◦ Diagrama de Implantação

16. Um modelo pode ser visto como uma
representação idealizada de um sistema a ser
construído
Maquetes de edifícios e de aviões e plantas
de circuitos eletrônicos são apenas alguns
exemplos de modelos
Uma simplificação da realidade que nos ajuda
a entender um problema complexo

17. Ajuda no gerenciamento da complexidade
inerente ao desenvolvimento de software
Ajuda na comunicação entre as pessoas
envolvidas
Ajuda na predição do comportamento futuro
do sistema

18. Representa o comportamento de um sistema
em termos de suas funcionalidades
Descrevem o que o sistema deve fazer, mas
não como isso será feito
Elementos
◦ Atores
◦ Casos de Uso
◦ Relacionamentos

19. Atores
◦ Representam qualquer entidade externa que
interage com o sistema
◦ Entidade externa: usuário, hardware, outro sistema,
etc.
◦ Formas de interação:
Enviar dados para o sistema
Receber dados do sistema
Enviar/Receber dados do sistema

20. Atores
◦ Implícitos
Atores que podem ser omitidos do diagrama
Inclusão não traz contribuição para a modelagem do
sistema
Ex.: Monitor, PC, Sistema Operacional, teclado, etc.

21. Relacionamentos
◦ Representam a interação entre:
Casos de uso e atores
Casos de uso
Atores

22. Casos de uso e atores
◦ Associação
Um ator pode interagir com mais de um caso de uso
Um caso de uso pode interagir com mais de um ator

23. Casos de uso e atores
◦ Associação
Notação – Ativação do Caso de Uso

24. Relacionamento
Entre casos de uso
◦ Inclusão (include)
◦ Extensão (extend)
◦ Generalização

25. ◦ Inclusão (include)
Um caso de uso inclui um outro caso de uso (subcaso
de uso)
Caso de uso incluído não faz sentido sozinho, não é
completo
Obrigatoriedade (sempre será executado)
Quando usar:
Detalhamento de casos de uso por meio de decomposição
Colocar em evidência partes comuns entre dois ou mais
casos de uso

26. ◦ Extensão (extend)
Caso de uso maior é estendido por um caso de uso
menor
Quando usar:
Usada para modelar casos de uso especiais que ocorrem
somente em determinadas circunstâncias (opcional)

27. ◦ Generalização
Representa o relacionamento entre um caso de uso
mais geral e um ou mais casos de uso específicos
Quando usar:
Representar a aplicação de um caso de uso geral em uma
situação particular
Situação particular: funcionalidades do caso de uso geral
devem ser complementada

28. Generalização

29. Entre atores
◦ Generalização
Representa que um ator é um caso especial de outro
ator

30. Tem como finalidade apresentar, de forma
detalhada, como deve ser executada uma
funcionalidade, ou seja, representa a
execução da funcionalidade passo-a-passo.
Os diversos autores, que tratam, atualmente,
deste assunto, apresentam diferentes
padrões e notação para descrição de caso de
uso. Adotaremos um modelo originado a
partir da fusão do que de bom foi encontrado
nesses autores, e acrescentamos, é claro,
nossa contribuição.

31. Nome do Caso de Uso – descrição do Nome
do caso de uso correspondente ao nome do
diagrama.
Sigla – é uma forma de denominar o caso de
uso, tornando mais fácil sua referência. Por
exemplo: UC001
Objetivo – é seção na qual deverá ser descrita
qual o objetivo do caso de uso;
Ator(es) – identifica qual ator(es) irão interagir
com o caso de uso que está sendo descrito.

32. Pré condição – descreve as restrições que
devem ser obedecidas para a execução do
caso de uso.
Pós Condição – descreve o que deverá ocorrer
no sistema após a execução do caso de uso.
É importante tomar o cuidado para descrever
somente aquilo que de fato irá impactar no
sistema e, de preferência, aquilo que tem
influência direta nas regras de negócio.

33. Fluxo – é o principal componente de uma
descrição de caso de caso de uso. Representa
a seqüência de passos a serem seguidos e
está classificado em: Fluxo Principal (ou
Básico), Sub Fluxo, Fluxo Alternativo e Fluxo
de Exceção (ou de erro);

34. Descreve o “caminho ótimo” do caso de uso,
ou seja, descreve a principal ação do caso de
uso sem se preocupar com exceções ou
quaisquer outros detalhes que possam
interferir no resultado do mesmo.

35. Descreve uma parte do fluxo principal.
Representa uma seqüência de passos que
serão SEMPRE executados, porém são
tratados de forma separada para tornar a
descrição do fluxo principal mais simples.

36. O Fluxo alternativo representa um caminho
opcional para o usuário que está interagindo,
ou seja, caso ele não queira seguir o caminho
principal (básico) ele tem a alternativa de
seguir outro caminho.

37. O Fluxo de Exceção ou Erro tem como
finalidade descrever como o sistema deverá
tratar erros que poderão ocorrer no fluxo
principal ou em nos fluxos alternativos e
sub-fluxos, ou seja, o fluxo de exceção
descreve algo que interferiu no caminho
ótimo mas que foi tratado pelo sistema.

38. Um sub-fluxo pode ser comparado a um
procedimento/função (procedure/function),
representando um desvio para se executar algo a
parte e depois voltar para o programa principal
(fluxo principal no nosso caso);
Uma diferença entre um sub-fluxo e um fluxo
alternativo é que o fluxo alternativo representa, na
maioria das vezes uma opção de escolha do
vezes,
usuário, isto é, uma escolha manual, e um sub-
fluxo representa uma escolha do sistema, ou seja,
uma escolha automática.

39. DIAGRAMA DE CLASSES

40. É um dos diagramas estáticos da UML e tem por objetivo
apresentar as classes do domínio do problema e os
relacionamentos entre as mesmas.
Mas o que são classes?
As classes agrupam um conjunto de entidades real ou abstratas que
possuem as mesmas características. Essas entidades são conhecidas
como objetos. Além disso, as classes servem como um molde para a
criação de novos objetos do mesmo tipo

41. Assim como no banco de dados, os dados só têm
sentido em uma base de dados quando estão
interligados, no um diagrama de classes deve
representar além das classes do sistema, os
relacionamentos entre as mesmas.
É importante ressaltar que este diagrama pode
ser elaborado em duas fases do desenvolvimento
de um software: na fase de análise e na fase de
projeto.

42. Na fase de análise, este diagrama é usado para
representar as classes do domínio do problema,
cujos dados devem ser armazenados na base de
dados do sistema.
Em relação à fase de projeto, pode-se dizer que o
mesmo é usado representar não apenas as
classes que contêm os dados a serem
armazenados, mas também outros tipos de classe
necessários à implementação software.

43. Componentes.
◦ Classes
◦ Relacionamentos.

44. Classes.
◦ De um modo geral, as classes são compostas por seus
atributos e seus métodos, sendo representadas por uma
“caixa” com três compartimentos

45. Visibilidade de atributos e métodos
◦ Private: indica que um atributo ou método só pode ser
visualizado e acessado dentro da própria classe. Na
UML, a visibilidade private é representada pelo símbolo
“-”.
◦ Público (public): um atributo ou método definido como
público é visível por qualquer por qualquer classe. A
notação para representar essa visibilidade é o símbolo
“+”.
◦ • Protegido (protected): um atributo ou método com
visibilidade protegido pode ser acessado pela própria
classe ao qual o mesmo pertence e por suas subclasses.
A visibilidade protected é representada na UML pelo
símbolo “#”.

46. Classes de entidade (Entity) – são entidades do
mundo real relevantes para o domínio do
problema, sendo seu principal papel representar
os dados a serem armazenados pelo sistema. Por
exemplo: Livro, Exemplar, Autor, etc.
b) Classes de controle (Control) – sua principal
função é controlar a execução de processos.
Normalmente, os métodos de uma classe dessa
natureza controlam transações que envolvem
várias classes de entidade.

47. Classes de fronteira (Boundary) – responsáveis
pela comunicação entre o mundo externo (atores)
e as classes de controle. Normalmente, são
implementadas na forma de interfaces gráficas
(telas). Exemplo: Tela de Cadastro de Livros, Tela
de Empréstimo de Exemplares.

48. Os relacionamentos representam a forma como
as classes de um sistema interagem entre si.
Duas ou mais classes podem se associar por
meio de quatro tipos de relacionamentos, os quais
são: associações, todo-parte, herança e
dependência.

49. Associações descrevem um vínculo existente entre duas classes,
sendo conhecidas como associações binárias. Para exemplificar
este tipo de relacionamento, considere as classes Aluno e Curso.
De acordo com o domínio de problema, um aluno deve estar
matriculado em um curso, ou seja, existe um vínculo entre essas
classes.

50. Todo-parte: indica que os objetos da classe A (todo) são compostos
por objetos da classe B (parte). Para exemplificar este conceito,
suponha um carro, o qual é formado por diversas peças. O carro
representa o todo e suas peças representam as partes que o
compõe.
Existem dois tipos de relacionamento todo-parte: agregação e
composição.
Agregação
Composição

51. Herança: Antes de iniciar a explicação do conceito de
herança empregada no diagrama de classes, vamos
entender o conceito de herança proposto pela genética.
Multiplicidade e Participação:

52. DIAGRAMA DE ESTADOS

53. Descreve os possíveis estados dos objetos de
uma classe
Elementos
◦ Estado inicial
◦ Estado final
◦ Estados
◦ Transição de estados

54. Notação
◦ Estado inicial
◦ Estado final
◦ Estado
◦ Transição

55. Classe Caixa

56. Eventos: é uma ação que exige a mudança de
estado do objeto como reação.
Ex: Ferver a água faz com que ela mude do
estado liquido para o gasoso.
A mudança de um estado é chamado de transição
de estado
Os estados e as transições de um objeto formam
um cliclo de vida do objeto.

58. Mostrar o fluxo de atividade de um processo.
Pode ser usado para detalhar um caso de uso
Fortemente empregado para representar fluxo de
negócio
Elementos
◦ Início do fluxo
◦ Final do fluxo
◦ Atividade
◦ Transição
◦ Junção/Bifurcação
◦ Seleção
◦ Condição de guarda
◦ Raias de navegação

59. Notação
◦ Início
◦ Final
◦ Atividade
◦ Transição
◦ Junção/Bifurcação
◦ Seleção
◦ Condição de guarda [condição]
◦ Raias de navegação

60. ◦ Atividade: é um passo simples num processo ou
na descrição do caso de uso.
◦ Estados de atividades: são as atividades
realizadas pelo sistema ou pelo ator.
◦ Transição: é a mudança que permite a passagem
de controle de uma atividade para outra.
◦ Desvios: são decisões que precisam ser tomadas
para permitir a continuação do fluxo de
atividades.

61. ◦ Bifurcação e junção de fluxo de controle: o
primeiro indica o início de atividades paralelas e
o segundo representar a união de fluxos
independentes.
◦ Intercalação: é utilizado após um desvio para
indicar que o fluxo seguirá o mesmo caminho
independente da condição de guarda satisfeita.
◦ Raias: são compartimentos que permitem a
separação das responsabilidades dos
participantes do diagrama de atividades.
◦ Estados inicial e final: indicam o início e o fim de
um fluxo, respectivamente.

62. Descrever os passos de um caso de uso.
Mostrar o fluxo completo do sistema,
representando a ordem de execução dos
casos de uso.
Modelar um algoritmo complexo.

64. É um diagrama usado para demonstrar interações entre objetos por
meio de troca de mensagens. (A bíblia)
Mostra a troca de mensagens entre os objetos.

65. Modelo de caso de uso descreve as tarefas que o sistema deve
realizar.
Descreve quais são os requisitos funcionais do sistema e quais são
as entidades do ambiente (atores) que interagem com o sistema.
Não descreve o comportamento interno do sistema.
Não responde às questões: Quais são as operações que devem ser
executadas internamente ao sistema? Quais objetos participam da
realização do caso de uso?

66. Modelo de classes do domínio descreve as classes que realizarão
as tarefas do sistema e o relacionamento entre as mesmas.
Fornece uma visão estrutural estática inicial do sistema.
Não responde às questões: De que forma os objetos colaboram
para que um determinado caso de uso seja realizado? Em que
ordem as mensagens são enviadas durante a realização de um
caso de uso?

67. O modelo de casos de uso e o modelo de classes do domínio têm o
objetivo de fornecer um entendimento do problema correspondente
ao sistema de software a ser desenvolvido.
O modelo de interações representa as mensagens trocadas entre
os objetos para a execução de cenários dos casos de uso do
sistema.
O modelo de interações responde às questões anteriores.

68. Permite armazenar em detalhes COMO os objetos interagem para
realizar uma tarefa.
Mostra como o sistema realiza casos de uso, ou cenários
particulares dos casos de uso.
Permite validar classes, responsabilidades e colaboradores
identificados anteriormente.
Permite refinar o modelo de classes do domínio.
Durante a construção do modelo de interações operações das
classes são identificadas.

69. Componentes
Ator
Objetos
Mensagens
Foco de controle

70. Ator
Realiza a interação com o caso de uso
Tem a mesma notação do diagrama de caso de uso.
Só interagem com a classe de fronteira.

71. Objetos
Representam as instâncias das classes.
São responsáveis por enviar ou receber mensagens.
São representados por uma caixa de retangular ou por um círculo,
acompanhados por uma linha tracejada, conhecida como linha de
vida do objeto.

72. Mensagens
Nas mensagens existe o objeto que envia a mensagem e outro que
recebe a mensagem.
As mensagens tem ser clara, ou seja, deve haver uma
comunicacão entendível entre ambos.
A seta das mensagens deve partir do objeto emissor para o
receptor.
As mensagens podem ser:
◦ Sícrona
◦ Assícrona
◦ Criacão de Objetos
◦ Retorno
◦ Reflexiva
◦ Destruicão

73. FOCO DE CONTROLE
O Foco de controle indica o momento ou período de
tempo em que um determinada mensagem de um objeto
está no comando da execução do sistema.
A notação do foco de controle é uma barra vertical fina
sobre a linha de vida do objeto.
Para as mensagens reflexivas, o foco de controle é
representado por uma barra vertical sobreposta à barra
da linha.

74. Sícrona
Indica que o objeto remetente espera que o objeto receptor
processe a mensagem enviada antes de recomeçar o seu
processamento.

75. Assícrona
Objeto remetente não espera a resposta da mensagem enviada
para prosseguir com o seu processamento.

76. Retorno
Indica o término de uma operação.
Mostra a resposta do objeto receptor referente à uma mensagem
síncrona recebida.

77. Criação de objetos
É uma mensagem que cria um objeto, ou seja, a partir
daquele momento o objeto passa a existir no sistema.

78. Reflexiva
O mesmo objeto é emissor e receptor ao mesmo tempo.
Um objeto envia uma mensagem para ativar um método
na sua própria classe.