CST - ADS - PPS - 01 Introducao

Fazer download em pdf ou txt
Fazer download em pdf ou txt
Você está na página 1de 66

Curso Superior de Tecnologia em

Análise e Desenvolvimento de Sistemas

Padrões de Projeto de Software


Professor: Felipe Schneider Costa - [email protected]
Professora: Simone Regina da Silva – [email protected]

1
Apresentação

•Apresentação dos professores(as) e dos alunos

2
Informações Gerais

•Contato:

✔Pelo SIGAA: sigaa.ifsc.edu.br

✔Por e-mail: [email protected]


[email protected]

✔Discord

3
Plano de Ensino e
Cronograma de Aulas

4
•A disciplina exige:
✔Dedicação e compromisso: disciplina.
✔Procurar os professores(as) quando estiverem com
dúvidas.

•Linguagem de programação: Java


•Ferramenta de programação: Netbeans
•Ferramenta de modelagem: Software Ideas Modeler

•Métodos de avaliação
•Nos trabalhos em grupo, até 4 alunos.

5
Agenda

•Padrões de Projeto: Conceito


•Revisão de Orientação a Objetos
✔O que é a Orientação a Objetos (OO)?
✔Fundamentos da OO:
▪Abstração;
▪Reusabilidade;
▪Extensibilidade e Manutenibilidade.
✔Identificação de Objetos;
✔O processo de abstração em OO na prática;
✔Definição de Classes;
✔Diagrama de Classes - UML;
•Atividade

6
O que são Padrões de Projeto?

7
O que são Padrões de Projeto

• O simples uso da OO não garante que obtenhamos


sistemas confiáveis, robustos, extensíveis e
reutilizáveis.

• O foco das metodologias de desenvolvimento está na


solução em si (o que e como) e não em suas
justificativas (porque).

• É difícil compartilhar a experiência entre experts e


novatos.

8
O que são Padrões de Projeto

"Cada padrão descreve um problema que ocorre outra e


mais outra vez no nosso ambiente, e então descreve o
âmago da solução deste problema, de forma que você
possa usar esta solução um milhão de vezes, sem fazer o
mesmo duas vezes.“.

"Um padrão de projeto sistematicamente nomeia, motiva


e explica um projeto genérico, que endereça um problema
de projeto recorrente em sistemas orientados a objetos.
Ele descreve o problema, a solução, quando é aplicável e
quais as consequências de seu uso."

9
O que é Orientação a Objetos?
Introdução à Orientação a Objetos

10
O que é a Orientação a
Objetos?

• Orientação a Objetos ( OO ) é um paradigma de


programação.

• Forma diferente de pensar e construir algoritmos e


programas para computadores.

11
O que é a Orientação a
Objetos?

• A POO é praticada com novos conceitos:


✔ Modelagem de Objetos;
✔ Atributos e comportamentos;
• Tudo passa a ser assumido como objetos, tal como
acontece no mundo real:
✔ Isso trás diferenças substanciais quanto à forma de
se pensar na construção de algoritmos!

12
O que é a Orientação a
Objetos?

•Vamos imaginar um sistema orientado a objetos:


✔Em um primeiro momento, não estamos preocupados
com a construção de cada objeto, mas com forma em
que os objetos interagem.

Usuário Programador

Rube Goldberg Machine

13
Fundamentos:
Abstração
Introdução à Orientação a Objetos

14
Abstração

Segundo o dicionário Houaiss:

“Operação intelectual em que um objeto de reflexão é


isolado de fatores que comumente lhe estão relacionados na
realidade”.

15
Abstração

• Ao observar um objeto podemos descrevê-lo;


• Como você descreve o objeto abaixo:
✔ Características?
✔ Funcionalidades?

16
Abstração

• Na abstração, iremos suprimir (abstrair) as características


imutáveis e irrelevantes;

17
Abstração

18
Abstração
Vitória!
10
• Vamos adicionar o tabuleiro de jogo
(ao lado) ao nosso processo criativo; 9
8
• Como você descreveria este tabuleiro
de forma abstrata? 7
✔ E se o tabuleiro tivesse curvas? 6
5
4
3
2
1
Inicio
19
Abstração

20
Fundamentos:
Reusabilidade
Introdução à Orientação a Objetos

21
Reusabilidade

• A Reusabilidade se refere a um conjunto de possibilidades


que surgem com a POO;

• A Herança é a possibilidade de reusabilidade mais marcante


na POO e será revisada mais tarde.

• Outra importante possibilidade de reusabilidade na POO é o


instanciamento múltiplo de objetos.

22
Reusabilidade

• Vamos assumir um pseudo sistema que precisamos


desenvolver.

• Este sistema será um jogo de tabuleiro e deverá conter:


✔ Um tabuleiro (anterior);
✔ Um dado para calcular o movimento (anterior);
✔ Jogadores (novos):
▪ Como descreveremos os jogadores de forma
abstrata?

23
Reusabilidade

24
Reusabilidade

• Com base no modelo de Jogador concebido, iremos


efetuar a construção de diversos objetos iguais!

• Com isto, teremos diversas diferentes instâncias de uma


mesma classe de objetos.

25
Múltiplas Instâncias

26
Fundamentos:
Extensibilidade e
Manutenibilidade
Introdução à Orientação a Objetos

27
Extensibilidade

• A extensibilidade se refere às condições associadas à


facilidade de se estender o software:
✔ Novas funcionalidades e novos recursos;
✔ As classes devem ser estruturas fracamente
acopladas que facilitam alterações;

• A Herança é também uma possibilidade de


extensibilidade marcante na POO.

28
Manutenibilidade

• A manutenibilidade se refere às condições associadas à


facilidade de se alterar o software:
✔ Correções de bugs;
✔ Alterações de rotinas;

• Quanto mais específicas forem as implementações de


cada classe e, idealmente, quanto menor o número de
responsabilidades de cada classe, melhor será sua
Manutenibilidade.

29
Extensibilidade e Manutenibilidade

Retomando o Jogador definido anteriormente:

Como podemos fazer ele se relacionar com os


demais elementos do jogo?

30
Extensibilidade e Manutenibilidade

Opções

Podemos estender as tarefas da classe Jogador; ou


Podemos criar uma nova Classe Jogo, que irá gerenciar o jogo.

31
Extensibilidade e Manutenibilidade

32
Identificação de Objetos
Classes e Objetos

33
Identificação de Objetos

•Ao nos depararmos com um novo problema, em um


diferente cenário:
1. Identificamos os objetos que fazem parte deste
cenário;
2. Separamos apenas os objetos que são relevantes ao
problema em questão;
3. Abstrairemos somente as ações e atributos
relevantes dos objetos envolvidos.

34
Identificação de Objetos

•Ao nos depararmos com um novo problema, em um


diferente cenário:
1. Identificamos os objetos que fazem parte deste
cenário;
2. Separamos apenas os objetos que são relevantes ao
problema em questão;
3. Abstrairemos somente as ações e atributos
relevantes dos objetos envolvidos;

35
Identificação de Objetos

Exemplo:
• Construir um jogo de tabuleiro:
✔ Principais objetos:
▪ Caixa do jogo;
▪ Manual de instruções;
▪ Mesa / espaço físico;
▪ Cadeiras;
▪ Dados;
▪ Jogador 1;
▪ Jogador 2;
▪ Jogador 3;
▪ Jogador 4;
▪ Tabuleiro;

36
Identificação de Objetos

•Ao nos depararmos com um novo problema, em um


diferente cenário:
1. Identificamos os objetos que fazem parte deste
cenário;
2. Separamos apenas os objetos que são relevantes
ao problema em questão;
3. Abstrairemos somente as ações e atributos
relevantes dos objetos envolvidos;

37
Identificação de Objetos

Exemplo:
• Construir um jogo de tabuleiro:
✔ Principais objetos:
▪ Caixa do jogo;
▪ Manual de instruções;
▪ Mesa / espaço físico;
▪ Cadeiras;
▪ Dados;
▪ Jogador 1;
▪ Jogador 2;
▪ Jogador 3;
▪ Jogador 4;
▪ Tabuleiro;

38
Identificação de Objetos

•Ao nos depararmos com um novo problema, em um


diferente cenário:
1. Identificamos os objetos que fazem parte deste
cenário;
2. Separamos apenas os objetos que são relevantes ao
problema em questão;
3. Abstrairemos somente as ações e atributos
relevantes dos objetos envolvidos;

39
O processo de abstração em
OO na prática
Classes e Objetos

40
O processo de abstração em
OO na prática

• Na programação orientada a objetos iremos planejar e


construir todo o software com objetos.

• No caso da POO baseada em classes iremos utilizar as


classes para representamos, de forma abstrata, um
determinado conjunto de objetos.

41
O processo de abstração em
OO na prática

• Toda Classe será planejada e escrita com base nos


Objetos que precisamos representar para montar nosso
software:
✔ Ela irá definir estado e comportamento dos objetos;
• Os primeiros elementos compositores de uma classe
que iremos definir são:
✔ Nome;
✔ Atributos;
✔ Métodos;

42
O processo de abstração em
OO na prática

• Nome da Classe:
✔ É a identificação da classe;
✔ Deve ser um nome que represente seu uso;
✔ Procuraremos seguir a mesma convenção utilizada
na linguagem Java:
▪ Primeiro caractere deve ser uma letra
maiúscula;
▪ Demais caracteres minúsculos;
▪ Evitar caracteres não ASCII;
o Sem acentuação e cedilha!
▪ Caso o nome seja composto, não se utiliza
espaço entre os nomes, apenas a primeira letra
dos demais nomes também serão maiúsculas.

43
O processo de abstração em
OO na prática

• Exemplos de nome de classes:


✔ Carro
✔ AlunoEscola
✔ CasaDaImobiliaria

• Nomes fora da convenção:


✔X
✔ Carro2
✔ aluno
✔ Maçaneta
✔ Carteiraestudante
✔ Profissional Autônomo

44
O processo de abstração em
OO na prática

• Atributos:
✔ Representam características ou estados do objeto;
✔ Deve ter um nome que represente seu uso;
✔ Procuraremos seguir a mesma convenção utilizada
na linguagem Java:
▪ Primeiro caractere deve ser uma letra
minúscula;
▪ Demais caracteres minúsculos;
▪ Evitar caracteres não ASCII;
o Sem acentuação e cedilha!
▪ Caso o nome seja composto, não se utiliza
espaço entre os nomes, apenas a primeira letra
dos demais nomes também serão maiúsculas;

45
O processo de abstração em
OO na prática

• Exemplos de nome de atributos:


✔ cor
✔ nomeCompleto
✔ altura
✔ Parado

• Nomes fora da convenção:


✔X
✔ Nome2
✔ Endereço
✔ data_de_nascimento
✔ nomedopai

46
O processo de abstração em
OO na prática

• Métodos:
✔ São funções ou tarefas que podem ser executados
pelo objeto;
✔ Deve ter um nome que represente seu uso;
✔ Procuraremos seguir a mesma convenção utilizada
na linguagem Java:
▪ Primeiro caractere deve ser uma letra
minúscula;
▪ Demais caracteres minúsculos;
▪ Evitar caracteres não ASCII;
o Sem acentuação e cedilha!
▪ Caso o nome seja composto, não se utiliza
espaço entre os nomes, apenas a primeira letra
dos demais nomes também serão maiúsculas;

47
O processo de abstração em
OO na prática

• Exemplos de nome de métodos:


✔ abrir()
✔ fecharConexao()
✔ agendarExecucaoDaRotina()

• Nomes fora da convenção:


✔ X()
✔ Abrir() ou ABRIR()
✔ fechar Conexao() ou fecharconexao()
✔ nome()

48
Exercícios

•Identifique os objetos e realize a abstração das classes


utilizando as convenções apresentadas para os seguintes
cenários:
1. Terminal rodoviário;
2. Partida de futebol;
3. Software que calcula a média de números.

49
Definição de Classes
Classes e Objetos

50
Definição de Classes

• Qual é o conceito central da tecnologia “orientada a


objetos”?
✔ Não são os objetos.
✔ Objetos são úteis, mas eles não são novidades:
▪ Cobol e C tem structures;
▪ Pascal tem records;
✔ Os objetos são importantes para descrever a
execução de um sistema OO, mas em OO tudo se
deriva de uma CLASSE.

51
Definição de Classes

• As classes são generalizações de objetos!


• Classes são comumente chamadas de estruturas
estáticas:
✔ Não mutáveis!

• “Uma classe é um tipo de dado abstrato equipado com


uma possível implementação parcial”;
Traduzido de Meyer, Bertrand. Object-oriented software
construction 2nd ed. Prentice Hall PTR, New Jersey, 1997.

52
Definição de Classes

• Todo Objeto é uma instância de alguma classe;

• Classes são como moldes ou modelos utilizados para a


construção dos objetos:

53
54
Definição de Classes

Projeto

Identificar Modelar

Objeto

Problema Atributo Classe


Método

Utilizar Instanciar

Utilização

55
Diagrama de Classes
Classes e Objetos

56
UML

• Unified Modeling Language:


✔ Linguagem de Modelagem Unificada;
• É uma linguagem de propósito geral utilizada para a
modelagem no campo da engenharia de software;
• Prove formas padronizadas para visualizar o desenho
de um sistema.

57
Diagrama de Classes

• Dentre as várias possibilidades de visualização de um


sistema, o diagrama de classes é responsável pela
representação do projeto de implementação do
software orientado a objetos;
• É a principal ferramenta utilizada na modelagem em
orientação a objetos:
✔ Utilizada no projeto do software, antes de sua
implementação.

58
Diagrama de Classes

É representado por uma tabela de 3 linhas:

59
Diagrama de Classes

Na primeira linha é informado o nome da Classe:

60
Diagrama de Classes

Na segunda linha são informados e descritos os atributos


da classe:

61
Diagrama de Classes

Na terceira linha são informados e descritos os métodos


(ações) da classe:

62
Diagrama de Classes:
atributos

Os atributos serão representados seguindo a especificação:

+ nomeDoAtributo : TipoDeDado

Modificador de
public, private, protected, default
acesso
Nome (identificação)
nome do atributo
do atributo
Separador do nome e Este sinal deverá estar presente, para evidenciar a
tipo declaração do tipo de dado.
Indica o que será armazenado por este atributo. Pode
Tipo de dado
ser definido por tipos de dados primitivos ou, por outras
associado ao
classes já existentes ou que ainda estão sendo
atributo
construídas.

63
Diagrama de Classes:
métodos

Os métodos serão representados seguindo a especificação:

+ nomeDaOperacao (argumento: Tipo) : TipoDeDado


Modificador de
public, private, protected, default
acesso
Nome (identificação)
nome do método
da operação
Serão informados dados adicionais que são
Argumentos*
necessários para a execução desta tarefa pelo objeto.
Separador do nome Este sinal deverá estar presente apenas quando o
e tipo* método tiver um retorno (função).
Tipo de dado* Indica o que será retornado por este método (função).

* campos opcionais
64
Diagrama de Classes:
software

• Para realizar a modelagem dos diagramas de classe,


iremos utilizar um software:
✔ Software Ideas Modeler
✔ www.softwareideas.net

65
Exercícios

No software, faça a representação do diagrama de classes:


1. Dos diagramas iniciados em exercício anterior:
a. Terminal rodoviário;
b. Partida de futebol;
c. Software que calcula a média de números;
2. Software que faz o cadastro de clientes de uma loja;
3. Software que faz o controle de estoque de um
almoxarifado;

66

Você também pode gostar