Orientação a Objetos - Software Livre Brasil

Análise de Sistemas
Visão Geral - Orientação a Objetos
Prof. José Honorato Ferreira Nunes
[email protected]
Resumo:
VISÃO GERAL:
Modelagem
de sistemas de software
O paradigma da orientação a objetos
Evolução histórica da modelagem de
sistemas
A Linguagem de Modelagem Unificada
(UML)
Modelagem de Sistemas de Software
ESTUDO DE CASO
Estudo de Caso
Para exemplificar o uso de modelos em
tarefas comuns, consideremos o Restaurante
Caseiro Hipotético, que serve refeições por
quilo, e onde o gerente, que também é a
pessoa que fica na balança e no caixa, anota
os pesos dos pratos dos clientes e os
pedidos que os garçons trazem em um
quadro-branco. A figura seguinte mostra o
quadro-branco do Restaurante Caseiro
Hipotético.
Estudo de Caso
Estudo de Caso
O quadro-branco mostrado na figura contém
espaços para anotar o peso dos pratos e os
pedidos de cada mesa do restaurante. Quando os
itens dos pedidos são servidos, o gerente anota,
ao lado do item no quadro-branco, o número de
itens ou peso do prato. Quando o cliente pede a
conta, o gerente se refere ao quadro-branco para
calcular o valor devido. O quadro-branco é um
modelo do restaurante, representando de forma
simplificada as informações do restaurante que
são necessárias para a contabilização dos pedidos
feitos para os garçons e gerente.
Estudo de Caso
O quadro-branco mostrado na figura contém
espaços para anotar o peso dos pratos e os
pedidos de cada mesa do restaurante. Quando os
itens dos pedidos são servidos, o gerente anota,
ao lado do item no quadro-branco, o número de
itens ou peso do prato. Quando o cliente pede a
conta, o gerente se refere ao quadro-branco para
calcular o valor devido. O quadro-branco é um
modelo do restaurante, representando de forma
simplificada as informações do restaurante que
são necessárias para a contabilização dos pedidos
feitos para os garçons e gerente.
O PARADIGMA DA
ORIENTAÇÃO A OBJETOS
•Introdução
•Classes e Objetos
•Mensagens
•O papel da abstração na orientação
a objetos
O PARADIGMA DA
ORIENTAÇÃO A OBJETOS
Introdução
O paradigma da orientação a objetos
O termo “paradigma da orientação a
objetos” é uma forma de abordar um
problema. Há alguns anos, Alan Kay, um dos
pais do paradigma da orientação a objetos,
formulou a chamada “analogia biológica”.
Nessa analogia, ele imaginou como seria um
sistema de software que funcionasse como um
ser vivo. Nesse sistema, cada “célula”
interagiria com outras células através do envio
de mensagens para realizar um objetivo
comum. Adicionalmente, cada célula se
comportaria como uma unidade autônoma.
O paradigma da orientação a objetos
De uma forma geral, Key pensou em como
construir um sistema de software a partir de
agentes autônomos que interagem entre si. Ele,
então estabeleceu os seguintes princípios da
orientação a objetos:
1.Qualquer coisa é um objeto.
2.Objetos realizam tarefas através da requisição de
serviços a outros objetos.
3.Cada objeto pertence a uma determinada classe.
Uma classe agrupa objetos similares.
4.A classe é um repositório para comportamento
associado ao objeto.
5.Classes são organizadas em hierarquias.
O paradigma da orientação a objetos
Mas que o paradigma da
orientação a objetos tem a ver
com a modelagem de sistemas?
O paradigma da orientação a objetos
Antes da orientação a objetos, um outro
paradigma era utilizado na modelagem de
sistemas: o paradigma estruturado. Nesse
paradigma, os elementos são dados e
processos. Processos agem sobre dados para
que um objetivo seja alcançado.
Por outro lado, no paradigma da
orientação a objetos, uma unidade autônoma
que contém seus próprios dados que são
manipulados pelos processos definidos para o
objeto e que interage com outros objetos para
alcançar um objetivo.
O paradigma da orientação a objetos
É o paradigma da orientação a objetos
que os seres humanos utilizam no cotidiano
para a resolução de problemas. Uma pessoa
atende a mensagens (requisições) para
realizar um serviço; essa mesma pessoa envia
mensagens a outras para que estas realizem
serviços.
Por que não aplicar essa mesma forma
de pensar a modelagem de sistemas?
O paradigma da orientação a objetos
Pode-se concluir que a orientação a
objetos, como técnica para modelagem de
sistemas, diminui a diferença semântica entre
a realidade sendo modelada e os modelos
construídos.
Classes e objetos
Classes e objetos
Classes são estruturas das linguagens de
programação orientadas a objetos para conter, para
determinado modelo, os dados que devem ser
representados e as operações que devem ser
efetuadas com estes dados.
Cada classe deve ter um nome que seja
facilmente associável ao modelo que a classe
representa.
Classes e objetos
Classes são escritas com os recursos e
regras da linguagem de programação
orientada a objetos para implementação dos
modelos, mas em muitos dos casos as
classes são somente moldes ou formas que
representam os modelos abstratamente.
Para
representação
de
dados
específicos usando classes será necessária a
criação de objetos ou instâncias desta
classe.
Classes e objetos
Um objeto ou instância é uma
materialização da classe, e assim pode ser
usado para representar dados e executar
operações.
Para que os objetos ou instâncias
possam ser manipulados, é necessária a
criação de referências a estes objetos, que
são basicamente variáveis do tipo da classe.
Classes e objetos
Fazendo uma analogia, uma classe poderia
ser considerada como sendo uma planta de
prédio, que descreve o prédio mas não
corresponde fisicamente a ele, enquanto que os
prédios construídos de acordo com aquela planta
seriam as instâncias. Similarmente, uma ficha
de
matrícula
em
branco,
sem
conter
informações, seria uma classe enquanto que
várias
fichas
daquele
tipo,
preenchidas,
corresponderiam à instâncias daquela classe. O
nome ou número de cada um destes prédios
seria a referência às instâncias da planta do
prédio.
Classes e objetos
É importante notar que uma classe é uma
abstração das características de um grupo de
coisas do mundo real. Na maioria das vezes, as
coisas do mundo real são muito complexas para
que todas as suas características sejam
representadas em uma classe. Além disso, para
fins de modelagem de um sistema, somente um
subconjunto de características pode ser
relevante. Portanto, uma classe representa uma
abstração das características relevantes do
mundo real.
Mensagens
Mensagens
Objetos não executam suas operações
aleatoriamente. Para que uma operação em um
objeto seja executada, deve haver um estimulo
enviado a esse objeto.
Se um objeto for visto como uma entidade
ativa que representa uma abstração de algo do
mundo real, então faz sentido dizer que tal objeto
pode responder a estímulos a ele enviados (assim
como faz sentido dizer que seres vivos reagem a
estímulos que eles recebem).
Mensagens
Quando se diz na terminologia de
orientação a objetos que objetos de um
sistema estão trocando mensagens significa
que
esses
objetos
estão
enviando
mensagens uns aos outros com o objetivo de
realizar alguma tarefa dentro do sistema no
qual eles estão inseridos.
Mensagens
O papel da abstração na
orientação a objetos
O papel da abstração na orientação a objetos
Uma abstração é qualquer modelo que
inclui os aspectos mais importantes,
essenciais de alguma coisas, ao mesmo
tempo em que ignora os detalhes menos
importantes.
Abstrações
permitem
gerenciar
a
complexidade e concentrar a atenção nas
características essenciais de um objeto.
Uma abstração é dependente da
perspectiva: o que é importante em um
contexto pode não ser importante em outro.
O papel da abstração na orientação a objetos
O papel da abstração na orientação a objetos
Encapsulamento
Objetos possuem comportamento. O termo
comportamento diz respeito a operações realizadas
por um objeto e também ao modo pelo qual essas
operações são executadas. O mecanismo de
encapsulamento é uma forma de restringir o acesso
ao comportamento interno de um objeto. Um objeto
que precisa da colaboração de outro objeto para
realizar alguma tarefa simplesmente envia uma
mensagem a esse último. O método que o objeto
requisitado usa para realizar a tarefa não é
conhecido dos objetos requisitantes.
O papel da abstração na orientação a objetos
Encapsulamento
O objeto requisitante precisa conhecer quais
as tarefas que um outro objeto sabe fazer ou que
informação ele conhece. Para tanto, a classe de um
objeto descreve o seu comportamento. Na
terminologia da orientação a objetos, diz-se que um
objeto possui uma interface. Em termos bastantes
simples, a interface de um objeto é o que ele
conhece e o que ele sabe fazer, sem descrever
como o objeto conhece e faz. A interface de um
objeto define os serviços que ele pode realizar e
consequentemente as mensagens que ele recebe.
Uma interface pode ter varias formas de
implementação.
O papel da abstração na orientação a objetos
Encapsulamento
Através do encapsulamento, a única coisa que
um objeto precisa saber para pedir a colaboração de
outro objeto é conhecer sua interface. Isso contribui
para a autonomia dos objetos. Cada objeto envia
mensagens a outros objetos para realizar certas
tarefas, sem se preocupar em como as tarefas são
realizadas. A aplicação da abstração, neste caso,
está em esconder os detalhes de funcionamento
interno de um objeto.
O papel da abstração na orientação a objetos
Encapsulamento
O papel da abstração na orientação a objetos
Polimorfismo
O polimorfismo indica a capacidade de abstrair
várias implementações diferentes em uma única
interface.
CASO: Há algum tempo atrás, o controle remoto de
meu televisor quebrou. Um tempo depois, comprei um
videocassete do mesmo fabricante de meu televisor.
Para minha surpresa, o controle remoto do
videocassete também funcionava para o televisor!
Esse é um exemplo de aplicação do Princípio do
Polimorfismo. Note mais uma vez que a abstração
também é aplicada aqui: um objeto pode enviar a
mesma mensagem para objetos semelhantes, mas que
implementam a sua interface de formas diferentes.
O papel da abstração na orientação a objetos
Herança
A herança é outra forma de abstração utilizada
na orientação a objetos, ela pode ser vista como um
nível de abstração acima da encontrada entre classes
e objetos.
Na herança, classes semelhantes são agrupadas
em hierarquias. Cada nível de uma hierarquia pode
ser visto como um nível de abstração. Cada classe em
um nível da hierarquia herda as características das
classes nos níveis acima. Esse mecanismo facilita o
compartilhamento de comportamento comum entre
um conjunto de classes semelhantes. Além disso, as
diferenças ou variações de uma classe em particular
podem ser organizadas de forma mais clara.
O papel da abstração na orientação a objetos
Herança
EVOLUÇÃO HISTÓRICA DA
MODELAGEM DE SISTEMAS
*****Livro*****
A LINGUAGEM DE
MODELAGEM UNIFICADA
(UML)
UML - Unified Modeling Language
A UML é uma linguagem para especificar, visualizar, construir e documentar os
artefatos de sistema de software, bem como para modelar negócios e outros
sistemas que não sejam de software (OMG).
1.
ESPECIFICAR – construir modelos precisos, sem
ambiguidade e completos.
 Facilita comunicação

2.
Semântica – não é um “punhado” de gráficos
VISUALIZAR – representar os modelos em uma
linguagem gráfica de fácil entendimento.

“Um gráfico vale mais do que mil palavras”

Diversas perspectivas (caso de uso, classe, estado,…)
UML - Unified Modeling Language
A UML é uma linguagem para especificar, visualizar, construir e documentar os
artefatos de sistema de software, bem como para modelar negócios e outros
sistemas que não sejam de software (OMG).
3.
CONSTRUIR – mapear os modelos da UML em linguagem de
programação
 Geração de código automática a partir do modelo visual
 Geração do modelo visual a partir do código
3.
DOCUMENTAR – incorporar os documentos que descrevem o
sistema em várias perspectivas
 Artefatos para documentação do sistema podem ser
construídos através das representações gráficas da UML
 Ex: Requisitos mapeados através dos casos de uso
Visões de um Sistema
Visões de um Sistema
O desenvolvimento de um sistema de software
complexo demanda que seus desenvolvedores
tenham a possibilidade de examinar e estudar
esse sistema a partir de diversas perspectivas.
Um sistema pode ser descrito por cinco visões
interdependentes deste sistema.
Cada visão enfatiza aspectos diferentes do
sistema
Visões da UML
Visões da UML
• Visão de Casos de Uso - mostra a funcionalidade do sistema
comportamento do sistema através da ótica do cliente (usuário).
-
Visão Projeto - descreve o problema e a sua solução – define os aspectos
lógico e interno do sistema.
• Visão de Processo – trata a divisão do sistema em processos e
processadores – possui foco no desempenho e escalabilidade do sistema.
• Visão de Implementação - descreve a arquitetura física do sistema, em
termos de componentes de software e arquivos.
• Visão de Implantação – mostra a topologia do HW em que o sistema é
executado.
Visões da UML
Ao enfatizar um conjunto de aspectos do sistema, um modelo
dá uma visão do sistema.
A descrição completa do sistema pode exigir várias visões daí a necessidade de vários tipos de modelos.
Visões e a UML
• As visões são usadas em UML para descrever os diferentes
aspectos do sistema sendo modelado.
• Uma visão é uma abstração do sistema, formada por um
conjunto de diagramas.
• A partir de um conjunto de visões se chega a uma descrição
completa do sistema a ser construído
Os Diagramas da UML
Diagramas da UML
A UML prevê a utilização vários tipos de diagramas para
a modelagem de sistemas, descritos a seguir.
OBS: Nem todos os diagramas apresentados são de uso
obrigatório, sendo utilizados a depender da natureza do
projeto.
Diagramas propostos pela UML:
Diagrama de Classe
Esse diagrama define a estrutura das
classes utilizadas pelo sistema, determinando
os atributos e métodos possuídos por cada
classe, além de estabelecer como as classes se
relacionam e trocam informações entre si.
As Classes podem se relacionar com
outras
através
de
diversas
maneiras:
associação,
dependência,
especialização/generalização,
agregação
e
composição.
Diagrama de Classe
Diagrama de Classe
•
Notação: Exemplo
Diagrama de Objetos
É uma variação do diagrama de classes e
utiliza quase a mesma notação. A diferença é que o
diagrama de objetos mostra os objetos que foram
instanciados das classes, fornecendo uma visão dos
valores armazenados pelos objetos em um
determinado momento de sua execução.
Os diagramas de objetos não são tão
importantes como os diagramas de classes, mas
eles são muito úteis para exemplificar diagramas
complexos de classes ajudando muito em sua
compreensão.
Diagrama de Objetos
Diagrama de Sequência
Mostra a interação entre os vários objetos
de um sistema.
O mais importante aspecto deste diagrama
é que a partir dele percebe-se a sequência de
mensagens enviadas entre os objetos. As
mensagens enviadas por cada objeto são
simbolizadas por setas entre os objetos que se
relacionam.
O decorrer do tempo é visualizado
observando-se o diagrama no sentido vertical de
cima para baixo
Diagrama de Sequência
Diagrama de Caso de Uso
É utilizado para representar graficamente
os requisitos funcionais de um sistema.
Este diagrama pode ser usado em todas
as fases no desenvolvimento de um sistema,
desde a fase de levantamento de requisitos até
a fase de implantação.
Nele é encontrado os atores externos,
casos de uso e as associações entre eles.
Diagrama de Caso de Uso
Diagrama de Caso de Uso - Ator
Os atores representam o papel de uma
entidade externa ao sistema como um usuário,
um hardware, ou outro sistema que interage
com o sistema modelado. Os Atores são
representados como bonecos.
CLIENTE
ALUNO
Diagrama de Caso de Uso - Ator
•
ATOR:
– Várias pessoas podem ser representadas por um único ator:
Diagrama de Caso de Uso - Ator
•
ATOR:
– Uma pessoa pode atuar como mais de um ator:
Diagrama de Caso de Uso – Caso de Uso
O caso de uso se refere aos serviços,
tarefas ou funções que podem ser utilizados de
alguma maneira pelos usuários do sistema. No
diagrama ele é representado por uma elipse.
Representa quem faz o que (interage)
com o sistema, sem considerar o
comportamento interno do sistema.
Diagrama de Caso de Uso – Caso de Uso
•
CASO DE USO:
– Exemplos:
• Caso de uso de uma biblioteca: Emprestar Livro
• Caso de uso de um banco: Sacar Dinheiro
– Representação:
Emprestar
Livro
Sacar
Dinheiro
Diagrama de Caso de Uso – Caso de Uso
•
CASO DE USO:
Nomeando CASOS DE USO...
Nomeie o caso de uso segundo a perspectiva do ator
primário. Foque no objetivo deste ator.
Ex: Alugar filme X Registrar aluguel de filme.
Comece o nome do caso de uso com um verbo no infinitivo
(para indicar um processo ou ação). Ex: Sacar dinheiro
Utilize verbos concretos, fortes, ao invés de verbos genéricos
e fracos. Evite: processar, controlar, etc.
Diagrama de Caso de Uso – Caso de Uso
Diagrama de Caso de Uso - Relacionamento
Os relacionamentos representam:
as interações entre os atores que fazem parte
do diagrama
as interações entre os atores e os Casos de
Uso
as interações entre os Casos de Uso e outros
Casos de Uso
A associação entre um ator e um Caso de
Uso é representada por uma reta ligando o ator
ao Caso de Uso.
Diagrama de Caso de Uso - Relacionamento
•
Ex: Relacionamento de comunicação
Diagrama de Caso de Uso - Relacionamento
•
RELACIONAMENTO DE INCLUSÃO (INCLUDE):
– Inclusão
• Entre casos de uso
• Seqüência de interações em comum
• Um caso de uso (precisa de, é composto de) outro
Diagrama de Caso de Uso - Relacionamento
•
Ex: Relacionamento de INCLUSÃO (INCLUDE)
Diagrama de Caso de Uso - Relacionamento
•
RELACIONAMENTO DE EXTENSÃO (EXTEND):
– Extensão
• Entre casos de uso
• Indica que um caso de uso pode opcionalmente incluir outro
Diagrama de Caso de Uso - Relacionamento
•
Ex: Relacionamento de Extensão (EXTEND)
Porque a UML é composta por
tantos diagramas?
O objetivo disso é fornecer múltiplas visões
do sistema a ser modelado, analisando-o e
modelando-o sob diversos aspectos, procurando-se,
assim, atingir a completitude da modelagem,
permitindo que cada diagrama complemente os
outros.
Para auxiliar na construção dos diversos
diagramas oferecidos pela UML os profissionais
fazem uso de ferramenta Cases: Enterprise
Architect, VP-UML, Poseidon for UML, ArgoUML,
Rational Rose e Astah Professional.