ABSTRAÇÃO

 Um dos mecanismos para lidar com a complexidade inerente à

aplicação e ao SW na tarefa de desenvolvimento de sistemas

 Processo de focalizar atenção no nível de análise

apropriado para um dado interesse, pois enfatiza em
elementos considerados importantes, suprimindo a ênfase
sobre os demais elementos

 Utilização no contexto OO :

 Nas etapas de análise e projeto

 No conceito de classe

 No processo de generalização

ENCAPSULAMENTO

 Armazenamento de informações e comportamentos em um único

local, acessável somente pelo comportamento do próprio
objeto

 O único modo de acessar a estrutura da informação

escondida é pelo comportamento do próprio objeto

 Então, para usar um objeto :

 Não há necessidade de se conhecer como a sua

estrutura de informação e o seu comportamento estão
representados e implementados internamente

 Basta saber quais operações o objeto oferece

  Mensagens invocam operações

 Operações ativam métodos

 Métodos atuam sobre atributos

GRAU de VISIBILIDADE

 Abstração proporciona a visão externa de um objeto

 Encapsulamento não permite que objetos clientes

enxerguem internamente objetos servidores

 Abstração é quando o cliente de uma classe não

necessita saber mais do que está na sua interface
 Encapsulamento é quando o cliente de uma classe não é
capaz de saber mais do que está na sua interface
Associação :

 Ocorre entre objetos

 Expressa a possibilidade de um relacionamento entre os

objetos das classes envolvidas

 Denotada por um verbo

 Conduz a uma relação não hierárquica e não estrutural

Restrição de Cardinalidade

 Indica o número de instâncias que participam de uma

relação

 Denotada por Multiplicidade na UML

 Restringe o número de objetos que podem ser associados com

outros em uma relação

PAPEIS EM UMA ASSOCIAÇÃO

 Contexto no qual os objetos atuam

 Nome do papel identifica o papel desempenhado pela classe

em termos de associação

 Nome de papéis são parte da associação e não parte da

classe
 Nome de papéis são parte da associação e não parte da
classe
AUTORELACIONAMENTO

 Contexto no qual instâncias de um mesmo objeto se

relacionam

Paciente
Medico
nome
nome
atende idade
CRM
sexo
especialidade
alergia
foneContato
endereco

HERANÇA :

 Propagação de atributos e operações baseada em :

 Relação entre classes (is-a)

 Subclasses herdam de suas superclasses

 Relação entre uma classe e suas instâncias (instance-

of)

Instâncias herdam de sua classe

POSSIBILITA :

 Especificar informações e operações, herdáveis pelos

descendentes, no nível mais alto de apropriação
(Generalização)

 Criar uma nova classe com base na alteração de

classes existentes (Especialização)
INTERAÇÃO ENTRE OBJETOS :

 Objetos se comunicam através de mensagens

 Um objeto invoca a operação de outro objeto passando

argumentos

 A mensagem pode ter parâmetros especificados através de um

nome e um tipo

 Podem ser especificadas usando-se a sintaxe e a semântica

da linguagem de programação a ser utilizada

CASOS DE USO

 Descrever o negócio ou o sistema de informações em termos

de seus usuários

 Desempenhar papel relevante na ligação entre um modelo de

negócios com o seu sistema de informação

 Capturar requisitos, descrevendo como atores poderão usar

o sistema

 Planejar e controlar o desenvolvimento iterativo de

projetos de software, proporcionando Feedback regular aos
usuários sobre o andamento do projeto

 Servir de base para testes

 Um Caso de Uso é uma sequência de ações que um sistema

executa de modo a fornecer um resultado observável e que
agregue valor para um particular ator

 Orientado ao Processo e não à Implementação

 Portanto, diferente da decomposição funcional

tradicionalmente utilizada

 Independência da Implementação

 Foco no “O Quê o Sistema deve fazer”

 Deve representar uma transação entre um usuário e o
sistema com algum retorno útil para o usuário

 Permite identificar características requeridas de um

sistema de software com base em como cada ator usará o
sistema

 Pode ser visto como a descrição de uma sequência de ações

que o sistema executa para prestar um serviço a um
determinado ator

 Casos de Uso são desenvolvidos com base nas necessidades

de atores, de modo a assegurar-se que o sistema se tornará
o que os usuários esperam

 Cada Ator tem as suas próprias demandas sobre o sistema e

então requer o seu próprio conjunto de Casos de Uso

 Um Ator é alguém ou alguma coisa externa ao sistema que

interage com o sistema

 Qualquer entidade que pode interagir (trocar dados) com o

sistema

 Características :

 Faz interface com o sistema

 É sempre externo ao sistema, nunca fazendo parte do

sistema

 É incontrolável pelo sistema

 Representa um papel e não um usuário em específico

 Buscar no Domínio do Problema substantivos que indiquem :

 Pessoas;

 Papéis;

 Empresas;

 Departamentos;

 Sistemas;

 Módulos;

 Periféricos ou equipamentos;
  Etc.

Descrevendo Casos de Uso

 Descrição, na forma de texto informal ou sequência de

passos de uma funcionalidade, uso ou comportamento
específico a ser oferecido pelo sistema, do ponto de vista
do Ator :

 O quê o sistema deve fazer

 Qual a sequência de transações, na forma de diálogo

ocorrendo entre o Ator e o sistema, de modo a
refletir como o Ator pode usar o sistema

 Fluxo de eventos

 Independência da implementação

 Escrito na linguagem do domínio

 Deve incluir:

 Quando e como o caso de uso inicia e termina

 Quais são os atores

 Quais são os dados necessários

 Seqüência normal de eventos

 Descrição de quaisquer fluxos alternativos ou

excepcionais

 Gabarito Padrão deve conter:

 Nome

 Atores

 Pré-Condições

 Pós-Condições

 Fluxo principal

 Fluxos alternativos

 Fluxos de erros (Sugere problemas no sistema)

 Usar quando se necessita:

  Delimitar o escopo do sistema

 Definir o comportamento do sistema

 Facilitar a comunicação entre usuários, especialistas

do domínio e equipe do projeto

 Verificar e validar a arquitetura do sistema

 Representação gráfica da interação com os usuários.

 Composto de atores e casos de uso.

 Documenta os requisitos do sistema e respectivos usuários

(atores).

 Utilizado em todas as fases do desenvolvimento para

determinação do que o sistema deve fazer (análise),
determinação de prioridades de implementação (design) e
para validação pelos usuários (testes e implantação).

 Deve ser acompanhado pelas especificações de cada caso de

uso.

 Não tem nada especificamente de orientação a objetos.