SlideShare uma empresa Scribd logo
Universidade Positivo
Especialização em Engenharia de Software
Práticas de Desenvolvimento de Software
Tiago Barros | tiago@tiagobarros.org
Conteúdo do curso
• Construção de software
– O que é construção de software
– Construção de software dentro de um processo de
desenvolvimento
• Paradigmas de programação e a construção de
software
– Paradigmas de linguagens de programação
– Compilação e execução de programas
– Alocação de memória
Conteúdo do curso
• Arquiteturas de software
• Introdução aos Padrões de Projeto
• Tipos de Padrões de projeto
– Criacionais
– Arquiteturais
– Comportamentais
• Documentação de padrões de projeto
Avaliação
• Exercícios realizados em sala
• Identificação e documentação da aplicação de
técnicas de reengenharia, reuso e padrões no
projeto de desenvolvimento de software.
• Apresentação das mudanças na arquitetura, com
seus benefícios e custos.
Bibliografia
• Code Complete: A Practical Handbook of Software Construction. Steve
McConnell.
• Design Patterns: Elements of Reusable Object-Oriented Software. Erich
Gamma, Richard Helm, Ralph Johnson, John M. Vlissides.
• The Pragmatic Programmer: From Journeyman to Master. Andrew Hunt, David
Thomas.
• Software Engineering. Ian Sommerville.
• C.R.U.I.S.E – Component Reuse In Software Engineering. Eduardo Almeida,
Alexandre Alvaro, Vinicius Garcia, Jorge Mascena, Vanilson Burégio, Leandro
Nascimento, Daniel Lucrédio, Silvio Meira.
Práticas de Desenvolvimento de
Software
Construção de Software
Tiago Barros | tiago@tiagobarros.org
Construção de Software
• A etapa de construção consiste na parte “mão na
massa” da criação de alguma coisa
• Inclui alguns aspectos de planejamento, projeto e
verificação, mas é essencialmente execução
• Quais as fases de um projeto de software que
fazem parte da construção de software?
Construção de Software
Figura retirada do livro Code Complete
Construção de Software
Figura retirada do livro Code Complete
Construção de Software
O que significa
“codificar e
debugar”?
Construção de Software
• O que significa “codificar e debugar”?
• Projetar e codificar classes e funções
• Criar e nomear variáveis e tipos de dados corretamente
• Definir as estruturas de controle
• Fazer testes unitários e debugar o próprio código
• Fazer revisão de código
• Formatar e comentar o código
• Selecionar e integrar os componetes de software utilizados
• Otimizar o código
Construção de Software
Porque
construção de
software é
importante?
Construção de Software
• Porque construção de software é
importante?
• É uma grande parte do processo de desenvolvimento de
software
• É a parte central do processo de desenvolvimento de
software
• Foco na construção aumenta a produtividade
• A construção de software é a única atividade que é
garantida de acontecer e ser entregue em todo projeto
Construção de Software
Pontos chave
• Construção de software é a parte que o cliente
realmente compra
• A qualidade da construção afeta diretamente a
qualidade do software
• As principais atividades da construção são:
design detalhado, codificação, depuração e testes
unitários e de integração.
Práticas de Desenvolvimento de
Software
Paradigmas de Programação
Tiago Barros | tiago@tiagobarros.org
Construção de Software
O que é uma
linguagem de
programação?
Paradigmas de Programação
• O que é uma linguagem de programação?
– Conjunto de expressões, com regras sintáticas e semânticas,
para expressar um programa de computador
– __________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Construção de Software
O que é um
paradigma de
programação?
Paradigmas de Programação
• O que é um paradigma de programação?
– Modelo de programação suportado por linguagens que
agrupam certas características em comum
– Impactam na forma como um problema real é modelado
computacionalmente
– __________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Paradigmas de Programação
• Paradigma Imperativo
– É definido como uma sequência de comandos (ordens) que
modificam o estado (variáveis) de um programa, de acordo
com os dados de entrada, para produzir uma determinada
saída.
PROGRAMA
Comando...
Comando...
Comando...
DADOS
(estado)
ENTRADA SAÍDA
Paradigmas de Programação
• Paradigma Imperativo
– Vantagens
• Modelagem natural de aplicações do mundo real
• Eficiência (diretamente implementado pelos processadores)
• Bem estabelecido (dominante)
– Desvantagens
• Difícil legibilidade
• Problemas de manutenção, principalmente em grandes
sistemas
• Paradigma Orientado a Objetos
– Define uma aplicação como um conjunto de módulos (objetos
que são representados por classes), que possuem um estado
(variáveis) e operações que modificam este estado (métodos).
– É uma subclassificação do paradigma imperativo (não é uma
classificação de paradigma)
Paradigmas de Programação
CLASSE
Operação...
Operação...
Operação...
DADOS
(estado)
ENTRADA SAÍDA
CLASSE
Operação...
Operação...
Operação...
DADOS
(estado)
ENTRADA SAÍDA
CLASSE
Operação...
Operação...
Operação...
DADOS
(estado)
ENTRADA SAÍDA
Paradigmas de Programação
• Paradigma Orientado a Objetos
– Vantagens
• Modelagem natural de aplicações do mundo real
• Eficiência (diretamente implementado pelos processadores)
• Classes são abstrações auto-contidas de elementos do
mundo real (tipos complexos)
• Modularidade
• Reusabilidade
• Extensibilidade
• Bem estabelecido
– Desvantagens
• Semelhantes ao imperativo, mas amenizadas pela maior
estruturação do programa.
• Paradigma Funcional
– Define um programa como um conjunto de funções que fazem
o mapeamento dos valores de entrada em valores de saída,
sem o conceito de estado do paradigma imperativo.
– Funções são tratadas como valores e cada função é declarada
em termos de outras funções (programação declarativa).
Paradigmas de Programação
PROGRAMA
(função)
ENTRADA SAÍDA
Paradigmas de Programação
• Paradigma Funcional
– Vantagens
• Manipulação de programas mais simples (prototipação)
• Prova de propriedades
• Transformação (otimização)
– Desvantagens
• Difícil mapeamento do mundo real na linguagem de
programação
• Baixa eficiência devido à dificuldade da implementação nos
processadores
• Entrada e saída (formatação, tela, etc) possuem apens
mecanismos primitivos
• Paradigma Lógico
– Define um programa que formará conclusões a partir de um
conjunto de premissas (declarações).
– Possui um conjunto de fatos (declarações verdadeiras) e
regras (manipulação) que descrevem o domínio do problema a
resolver.
Paradigmas de Programação
PROGRAMA
(fatos, regras)
ENTRADA SAÍDA
Paradigmas de Programação
• Paradigma Lógico
– Vantagens
• Acumulam as mesmas vantagens do paradigma funcional
• Permite a concepção de aplicações em um alto nível de
abstração (através de associações de entrada e saída)
– Desvantagens
• Acumulam as mesmas desvantagens do paradigma
funcional
• Usualmente não possuem tipos nem funções de alta ordem
Práticas de Desenvolvimento de
Software
Conceitos Básicos de Desenvolvimento
Tiago Barros | tiago@tiagobarros.org
Conceitos Básicos
 Como funciona um compilador
 Como funciona a execução de um programa
 Variáveis e tipos de dados
Conceitos Básicos
Objetivos
• Entendimento de como um programa é compilado e
executado, no paradigma imperativo/orientado a objetos
• Entendimento de como funciona a execução de um programa
• Entendimento de como funcionam elementos básicos de um
programa
Conceitos Básicos
• Compilação em C/C++
– Arquivo fonte (.c / .cpp)
• Possui a implementação do código
• É compilado
– Arquivo de cabeçalho (.h)
• Possui a declaração dos símbolos
– Funções e variáveis
• Não é compilado
Conceitos Básicos
• Compilação em C/C++
– Arquivo fonte (.c / .cpp)
• O que não é encontrado, vai para a tabela de
simbolos para ser resolvido na ligação (linker)
• Cada arquivo fonte (.c / .cpp) gera um arquivo
objeto (.o)
– Arquivo de cabeçalho (.h)
• É incluído no arquivo fonte para que o arquivo
fonte “conheça” as declarações do cabeçalho
Conceitos Básicos
• Compilação em JAVA
– Arquivo fonte (.java)
• Possui a declaração e implementação da classe
• Cada arquivo fonte (.java) gera um arquivo objeto
(.class)
• Os arquivos .class são “executados” (interpretados)
pela máquina virtual
Conceitos Básicos
• Como Funciona um compilador
– Instruções
• Operação realizada por um processador
• Linguagem fonte
• Código intermediário
• Código de máquina
Conceitos Básicos
• Como Funciona um compilador
– Pré-processamento
• Substituição de termos (macros)
• Ativação de funcionalidades do compilador
• Compilação condicional
#include
#define
#pragma
#if / #ifdef / #else / #endif
Conceitos Básicos
• Como Funciona um compilador
– Compilação
• Transformar código fonte em código objeto
• Diferentes formatos de código objeto (dependente da
máquina)
• Código objeto pode ser diretamente executável
Conceitos Básicos
• Como Funciona um compilador
– Compilação > Erros:
• Definição de símbolos errada
• Falta de definição de símbolos
• Tipos de dados incompatíveis (impossível converter
diretamente)
• _________________________________
• _________________________________
• _________________________________
• _________________________________
Conceitos Básicos
• Como Funciona um compilador
– Ligação
• Juntar um ou mais códigos objeto e gerar um arquivo
executável
• Tabela de símbolos
– Exportados
– Importados
Conceitos Básicos
• Como Funciona um compilador
– Ligação > Erros
• Símbolos não existem
• _________________________________
• _________________________________
• _________________________________
• _________________________________
• _________________________________
• _________________________________
Conceitos Básicos
• Compilação dinâmica (nativa) em Java
– Código 100% interpretado chega a ser 10x mais
lento que código compilado
– Mas...
– Código compilado é 4 a 5 x maior que código
interpretado
– Tradeoff entre performance e tamanho do código
final
Conceitos Básicos
• Compilação dinâmica (nativa) em Java
– Utilizar compilação adaptativa
• Compila os métodos considerados “hot spots” para
código nativo
• Mantêm o restante como bytecode
• Aumenta o uso de memória, mas também aumenta a
performance
Conceitos Básicos
• Como Funciona a execução de um
programa
– Memória
• Armazenamento
• Programas e dados
Address Data
0x00000000 0101100100110011
0x00000001 0001000110011110
0x00000002 1110010101010111
… …
0x00FD347B 0001010110110101
… …
0xFFFFFFFF 0011010101110110
Conceitos Básicos
• Como Funciona a execução de um
programa
– Unidade de processamento
• Carregar e decodificar
instruções
• Controlar unidade
de execução
PC
Decoder
Memory
Execution
Unit
Conceitos Básicos
• Como Funciona a execução de um programa
Registers
MemoryALU
Conceitos Básicos
• Como Funciona a interpretação de uma classe Java
– A VM recebe como parâmetro a classe a ser executada
– A Classe é “carregada” na máquina virtual
– O interpretador da VM procura o método main na classe
– O interpretador inicia a execução do bytecode que está no
método main
• Caso a classe não tenha um método main, uma exceção é
“jogada”
Conceitos Básicos
• Class loader  carrega cada uma das classes e verifica se as classes estão ok
• Methods area  quando uma classe é carregada, os seus bytes codes são salvos nessa
região
• Heap  área de execução. Todos os objetos criados são colocados aqui
• Java Stacks  pilhas de execução que guardam as chamadas dos métodos. Quando não
existe mais nenhuma pilha, a VM é finalizada
• Execution engine  interpretador do bytecode
• Como Funciona a
interpretação de
uma classe Java
Conceitos Básicos
• Variáveis e tipos de dados
– Tamanho do barramento de dados do
processador (palavra)
char
int
short
long
Ponteiro
word
c c c c
short short
int
long
pointer
Áreas de memória de um programa
Memória e tipos de dados
Variáveis ponteiros
Memória
Memória
• Classificação
Memória
• Áreas de armazenamento de variáveis de um programa
– memória estática
– pilha
int g = 0;
int main()
{
int x = 20;
g = x;
}
ESTÁTICA
100 (g) 0
PILHA
200 (x) 20
20
Memória
• Áreas de armazenamento de variáveis de um programa
– Heap
int* g = NULL;
int main()
{
int x = 20;
g = (int*)malloc(sizeof(int));
*g = x;
}
ESTATICA
100 (g) 0x00000000
PILHA
200 (x) 20
0x00001000
HEAP
1000 ????????20
Memória
• Áreas de armazenamento de variáveis de um programa
– Desalocando memória
int* g = NULL;
int main()
{
int x = 20;
g = (int*)malloc(sizeof(int));
*g = x;
free(g);
}
ESTÁTICA
100 (g) 0x00000000
PILHA
200 (x) 20
0x00001000
HEAP
1000 ????????20
Memória
• Variáveis ponteiros
– Endereços de memória
• O operador referência: &
• O operador desreferência: *
– Declarando ponteiros
int i=10;
int *intPtr;
intPtr = &i;
Memória
• Variáveis ponteiros
– O que significa:
&i
*i
&intPtr
*intPtr
– Os operadores new e delete
int *intPtr = new int;
...
delete intPtr;
Memória
• Variáveis ponteiros
int x = 10;
char c = ‘c’;
int* pi;
char* pc = &c;
int** ppi;
int*** pppi;
pc = “uma string”;
pi = &x;
ppi = π
pppi = &ppi;
ADDRESS DATA
0x00000100 (x) 10
0x00000104 (c) ‘c’
0x00000108 (pi) 0x00000100
0x0000010C (pc) 0x00000104
0x00000110 (ppi) 0x00000108
0x00000114 (pppi) 0x00000110
.......................... ....................
0x00001100 “uma string”
0x0000110C
0x00001100
Memória
• Variáveis ponteiros – Exercício! 
int global = 0;
int inc(int* num)
{
return save(*num = *num + 1);
}
int save(int y)
{
global = y;
}
void main()
{
int *ptr = (int*)malloc(sizeof(int));
inc(ptr);
printf(“%d”, *ptr);
printf(“%d”, global);
}
1. Descreva o que
acontece com a memória
do programa ao lado,
conforme visto nos
exemplos anteriores;
2. O programa ao lado
compila?
3. Existe algum erro de
execução no programa?
Memória
• Tipos de dados derivados – Arrays
void main()
{
char array[] = “Hello!”;
char *ptr = array;
*ptr = ‘W’;
ptr++;
*ptr = ‘o’;
ptr++;
*ptr = ‘r’;
ptr+= 2;
*ptr = ‘d’;
}
PILHA
100 (array) H
101 e
102 l
103 l
104 o
105 !
106 0
107
0x00000100108 (ptr)
10C
W
0x000001010x00000102
o
r
d
0x00000104
Memória
• Tipos de dados derivados – Estruturas
typedef struct __point
{
int x, y;
} Point;
void inc (Point q)
{
q.x++;
q.y++;
}
void main()
{
Point p;
p.x = 10;
p.y = 20;
inc(p);
}
PILHA
p
100 (x)
104 (y)
10
20
q
108 (x) 10
10C (y) 20
11
21
Memória
• Tipos de dados derivados – Estruturas
typedef struct __point
{
int x, y;
} Point;
void inc (Point* ptr)
{
p->x++;
p->y++;
}
void main()
{
Point p;
p.x = 10;
p.y = 20;
inc(&p);
}
PILHA
p
100 (x)
104 (y)
108 (ptr) 0x00000100
10
20
11
21
Memória
• Tipos de dados derivados – Uniões
#define B 0
#define G 1
#define R 2
#define A 3
#define MAX_COMP 4
typedef union __color
{
int value;
char comp[MAX_COMP];
} Color;
void main()
{
Color color;
color.value = 0;
color.comp[R] = 0xFF;
}
PILHA 3 2 1 0
100
(color)
value
comp
0 0 0 0255
Memória em Java
• A “carga” de uma classe java equivale a “carga” de um código nativo para
ser executado. As classes ficam na “área de métodos”
• Todo objeto criado em java é colocado na heap java (similar ao heap nativa)
– No momento de executar a VM no PC é possível passar como parâmetro o
tamanho máximo da heap java
• Java não requer que o código “desaloque” explicitamente memória
– A VM utiliza um “garbage collector”
– Quando um objeto da heap não tem mais nenhum outro objeto
apontando para ele, o coletor de lixo o remove da memória
– É necessário então “limpar” referências que não são mais utilizadas
(atribuir para null), caso contrário pode causar memory leak
• Variáveis locais a um método são colocadas na pilha de java (similar a
pilha nativa)
Maquina Virtual JAVA
• A HotSpot VM otimiza o gerenciamento de memória por idades
(generational).
• O heap da maquina virtual é dividida em young generation, old gereration
e permanent generation de acordo com a idade do objeto
Maquina Virtual JAVA
• Na Young generation estão os objetos considerados com tempo curto
relativo a um intervalo de coletas.
• A young generation é dividida em 3 espacos :
– um eden
– dois espaços “Survivor”(to-space e from-space).
– As alocações acontecem do eden para o from-space.Quando estes estão
preenchidos a coleta na Young generation é feita.
– Geralmente a young generation é muito menor em relação ao tamanho da
heap.Isto leva a pequenas mas freqüentes pausas na young generation durante
a execução do garbage collection.
Maquina Virtual JAVA
• Objetos que sobreviventes a um determinado numero de coletas são
movidos(promovidos) para a old generation.
• A old generation é tipicamente maior em relação a Young o que leva a
pausas maiores e menos freqüentes .
• A permanent generation é usada para armazenar classes de objetos e
meta dados relacionados.
Maquina Virtual JAVA
Chamada de funções e mudança de contexto
Passagem de parâmetros
Ponteiros para funções
Funções
Funções
• Declaração de funções
tipo nome(argumentos...);
• Corpo das funções
tipo nome(argumentos...)
{
instruções;
return expressão_de_retorno;
}
Funções
• Chamada de funções / Pilha de execução
int fib(int x)
{
int ret = 1;
if (x > 1)
ret = fib(x-1)+ fib(x-2);
return ret;
}
void main()
{
int n = 3;
n = fib(n);
}
PILHA
100 (n) 3
104
108 (x) 3
10C (ret) 1
1
110
114 (x) 2
118 (ret) 1
11C
120 (x) 1
124 (ret) 1
110
114 (x) 0
118 (ret) 1
1
2
2
3
3
3
110
114 (x) 1
118 (ret) 1
1
Funções
• Passagem de parâmetros / Retorno
– Por valor
• Variável é duplicada na pilha e seu valor é copiado
• C / C++ / Java
– Por referência
• A referência (endereço) da variável é passada
• C++
Funções
• Funções e arrays em C
– Arrays como argumentos
int add(int intArray[], int numElemnetos);
int add(const int *intArray, int
numElemnetos);
– Arrays como retorno
int * createArray(int numElementos)
Funções
• Funções e estruturas em C / C++
– Estruturas como argumento e retorno de funções: são
passadas por valor (cópia)
struct TBall{ int x, y;};
void move(TBall ball);
TBall createBall(int x, int y);
– Para evitar o overhead da cópia, costuma-se passar
estruturas por referência constante:
void move(const TBall &ball);
Funções
• Funções em Java (Métodos)
– Java passa seus objetos como ponteiros!
– Ponteiros são endereços passados por valor!
class TBall {
public int x, y;
}
class c1 {
public void moveBall(TBall ball) {
ball.x += 1;
ball.y += 1;
}
public void createBall(TBall ball) {
ball = new TBall();
}
}
Funções
• Ponteiros para funções
int funcao(int i);
int (*ponteiro_para_funcao)(int i);
ponteiro_para_funcao = funcao;
int ret, arg;
ret = (*ponteiro_para_funcao)(arg);
Exercício
• implementar um stream de dados na memória de acordo com os
seguintes requisitos:
– O stream deverá ter uma quantidade de memória previamente alocada e deverá
prever casos de falta de memória, alocando mais se for preciso.
– O stream de dados poderá armazenar dados dos seguintes tipos: char, short, int,
long, float.
– Deverá ser implementada um conjunto de funções para escrita e leitura de cada tipo
de dados no stream.
– O stream funcionará como uma fila FIFO, ou seja: o primeiro dado que for escrito
será o primeiro dado a ser lido.
– Cada tipo de dado inserido no stream deverá ocupar apenas a memória necessária
(não deverá haver desperdício de memória, ou seja, alocação de memória a mais do
que o necessário para armazenar o tipo de dado)
– O usuário do stream é quem deverá se preocupar com a ordem de inserção /
remoção de dados do stream, ou seja: se forem inseridos 2 int e depois tentar ler 2
char, deverão ser retornados os 2 primeiros bytes do primeiro int.
– Deverão ser tratados os erros de falta de memória (na escrita do stream) e falta de
dados (na leitura do stream)
Exercício
• Implementação em C
– Implementar uma estrutura de dados para armazenar o stream e as
seguintes funções para manipular esta estrutura:
– void WriteChar(char c);
– void WriteInt(int i);
– void WriteShort(short s);
– void WriteLong(long l);
– void WriteFloat(float f);
– char ReadChar();
– int ReadInt();
– short ReadShort();
– long ReadLong();
– float ReadFloat();
Exercício
• Implementação em C++
– Implementar a seguinte classe:
class Stream
{
public:
//construtor: initMemory é a mem inicial alocada
Stream(int initMemory);
// destrutor: libera toda memória utilizada
~Stream()
// métodos de escrita no stream
void WriteChar(char c);
void WriteInt(int i);
void WriteShort(short s);
void WriteLong(long l);
void WriteFloat(float f);
// métodos de leitura do stream
char ReadChar();
int ReadInt();
short ReadShort();
long ReadLong();
float ReadFloat();
private:
// declare aqui todas as variáveis necessárias
// para implementação deste código
};
Exercício
• Testes
– Implementar código de testes para testar o uso do
stream, prevendo as situações de erro e verificando a
completude do teste.
Práticas de Desenvolvimento de
Software
Design de Software
Tiago Barros | tiago@tiagobarros.org
Design de Software
• Processo de projetar um software
• Concepção de um esquema para transformar a
especificação em um software desenvolvido
• O design de software é bastante útil em projetos
pequenos e indispensável em projetos grandes
• O design deve ser detalhado na quantidade de
níveis necessária
Design de Software
Características de um bom Design
• Minimização da complexidade
• Facilidade de entendimento e manutenção
• Baixo acoplamento
• Estensibilidade
• Reusabilidade
• Portabilidade
• Alto “fan-in” (várias classes usam uma classe)
• Médio a baixo “fan-out” (uma classe usa poucas classes)
Níveis de Design
Figura retirada do livro Code Complete
Arquitetura de Software
• Design de software de alto nível
• Abstração do sistema computacional em módulos
(sub sistemas)
• Com o crescimento dos sistemas computacionais, é
preciso tomar decisões que vão além dos algoritmos
e estruturas de dados utilizados
Arquitetura de Software
• A arquitetura de software trata de decisões sobre:
– os componentes que formarão o sistema;
– o papel que cada componente representará no sistema;
– protocolos de comunicação entre os componentes;
– formas de acesso a dados;
– distribuição dos componentes do sistema;
– atributos de qualidade do sistema (desempenho,
escalabilidade, etc);
Exercício
• Seminário sobre arquiteturas de software
– Apresentar e discutir os principais modelos de arquitetura
utilizados no desenvolvimento de software;
– Apresentar e discutir os modelos de arquitetura utilizados
no projeto; (porque do uso, benefícios e custos)
– Exemplos:
• Arquitetura de repositório;
• Arquitetura cliente-servidor;
• Arquitetura em camadas;
• Arquitetura orientada a serviços;
• Arquitetura de objetos distribuídos;
• etc.
Design de Software
Voltando ao
Design...
Design de Software
• Rittel e Webber definem design como um problema
cruel: a única forma de definir este problema é
resolvendo o problema ou uma parte dele
Design de Software
Porque?
• Design envolve restrições e trade offs
• Design é não determinístico
• Design é um processo heurístico
Design de Software
Entretanto...
• Design pode ser capturado
• Design é uma mistura de conhecimento e
criatividade
• Soluções de design que já foram resolvidas são
reutilizadas, formam padrões
Padrões de Projeto – Design Patterns
Design de Software
Então porque
Design
Patterns?
Design de Software
Então, porque Design Patterns?
• Uma vez que definimos o problema através da sua
resolução, podemos reusar esta resolução
• Design Patterns permitem aos desenvolvedores
compartilhar conhecimento sobre o design
• São soluções de Design comprovadas para um
determinado problema dado um contexto
Práticas de Desenvolvimento de
Software
Design Patterns
Tiago Barros | tiago@tiagobarros.org
Design Patterns
Histórico
• Christopher Alexander (1970)
– “Each pattern describes a problem that occurs over and over again in our environment and
then describes the core of the solution to that problem in such a way that you can use this
solution a million times over without ever doing it the same way twice.”
• Patterns apareceram novamente na OOPSLA
conference (1987).
• Gamma, Helm, Johnson and Vlissides (the Gang
of Four, or GoF) escreveram em conjunto o
famoso livro: Design Patterns: Elements of
Reusable Object-oriented Software.
Design Patterns
Conceitos
• Patterns
– Um padrão é uma forma completamente compreendida de um
modelo aceito ou proposto para imitação… de acordo com o
dicionário.
– No nosso dia-a-dia encontramos vários problemas que já
ocorreram e vão ocorrer de novo. Design Patterns nos
permitem compartilhar a resolução destes problemas, que são
bem conhecidos e já foram bem resolvidos.
Design Patterns
Conceitos
• Anti-Patterns
– Demosntram uma resolução errada, que deve ser evitada.
– Descrevem como sair de um problema e como proceder para
encontrar um solução adequada.
Design Patterns
Conceitos
• Tipos de padrões
– Padrões Arquiteturais
• Descrevem a estrutura e o relacionamento entre os componentes de
um software.
– Padrões de Análise
• Descrevem modelos cuja semântica os fazem aplicáveis a domínios de
aplicação específicos.
– Padrões de projeto
• Identificam as relações internas de um grupo de componentes de
software e descrevem a responsabilidade e colaboração entre eles.
– Idiomas
• Descrevem como implementar aspectos de sistemas de software em
uma linguagem de programação específica.
Design Patterns
Conceitos
• Design Patterns
– “Descrição de objetos e classes que estão relacionados e
customizados para resolver um problema de projeto, em um
determinado contexto.“
– GoF define seus design patterns como:
• “A design pattern names, abstracts, and identifies the key aspects of a
common designstructure that make it useful for creating a reusable
object-oriented design. The design pattern identifies the participating
classes and instances, their roles and collaborations, and the
distribution of responsibilities.”
Design Patterns
Aplicabilidade
• Por que usar design patterns?
– Foram provados. Patterns refletem a experiência, conhecimento e
insights dos desenvolvedores que já utilizaram os padrões com sucesso
em seu próprio código.
– São reusáveis. Patterns proveem uma solução pronta que pode ser
adaptada para diferentes problemas se necessário.
– São expressivos. Patterns proveem um vocabulário comum de soluções
que podem expressar soluções maiores de forma sucinta.
Design Patterns
Aplicabilidade
• Quando usar um design pattern?
• Responda as seguintes questões:
• As consequencias do uso do padrão são aceitáveis?
• Existe uma solução mais simples?
• Existe algum padrão que ataca problemas similares?
• Existe alguma restrição no uso do padrão?
• Regras:
• Preste atenção no contexto e no problema do padrão, verificando se o padrão é
adequado e consistente com seu contexto.
• Uso excessivo de padrões pode criar um projeto pesado.
• Algumas pessoas acreditam que o uso de padrões pode limitar a criatividade do
desenvolvedor.
Design Patterns
Aplicabilidade
• Escrevendo padrões: um template
– Pattern Name and Classification
– Intent
– Also Known As
– Motivation
– Applicability
– Structure
– Participants
– Collaborations
– Consequences
– Implementation
– Sample Code
– Known Uses
– Related Patterns
Design Patterns
Exemplo
• Manager Design Pattern (from Realtime Mantra Pattern Catalog)
– Intent
• The main intention here is to manage multiple entities of same type. For
example, a Terminal Manager will manage all the Terminal objects under its
control. This will involve Terminal creation, Terminal deletion, message routing
to the Terminal and coordination of activities like switchover between two
Terminals.
– Also Known As
• Manager-Managed Design Pattern
• Managed Object Design Pattern
Design Patterns
Exemplo
• Manager Design Pattern cont(2/9)
– Diagram
Manager
objectArray[]
handleMessage(Message msg)
Handles all messages to all objects
that includes creation and deletion
Array that holds the objects
ManagedObject
handleMsg1()
handleMsg2()
.
.
.
Methods that handles each kind
of message sent to object
Design Patterns
Exemplo
• Manager Design Pattern (cont 3/9)
– Motivation
• Consider the case where no Manager object is defined. Each Terminal object has
to know about all other Terminal objects for purposes of message routing and
coordination. Also, in the absence of a Manager there will be no single point for
Terminal object creation and deletion.
– Applicability
• This design pattern can be applied whenever a system needs to support many
entities of same or similar type. The Manager object is designed to keep track of
all the entities. In many cases, the Manager will also route messages to
individual entities.
Design Patterns
Exemplo
• Manager Design Pattern (cont 4/9)
– Structure
• The Manager object may manage all the entity objects by implementing
standard data structures like array or STL map. The idea is to have a quick way
of indexing to get to a particular entity. This indexing capability is required to
quickly access an entity from a numerical id assigned to the entity. This
numerical id will be typically included in all the messages received for these
entities.
– Participants
• The Manager object and the Managed Entities are the main actors in this design
pattern. A single Manager object manages multiple entity objects.
Design Patterns
Exemplo
• Manager Design Pattern (cont 5/9)
– Collaboration
• Manager to Managed Entity communication is typically done via manager
invoking methods for the individual entities. The return value of a method is
used by the entity to communicate with the manager. The routing of messages
is also achieved by invoking the message handler for the entity object.
• In more complicated designs, the Manager and entity may communicate via
local messages. In such cases, the various coordination design patterns like
parallel and serial coordination may be used.
Design Patterns
Exemplo
• Manager Design Pattern (cont 6/9)
– Consequences
• The Manager object introduces a clean interface for communicating with any of
the managed entities. It also provides a centralized point for coordinating
operations on multiple entity objects.
– Implementation
• As mentioned earlier, the Manager object contains an array or STL map of all
the entities under its control. The entity collection may be maintained as
pointers to the entity objects or entity objects themselves.
Design Patterns
Exemplo
• Manager Design Pattern (cont 7/9)
– Sample Code and Usage
• class TerminalManager
• {
• Terminal* terminals[MAX_TERMINALS];
• public:
• void handleMessage(Msg* pMsg)
• {
• switch (pMsg->getType())
• {
• case CREATE_TERMINAL:
• terminals[pMsg->getTerminalId()] = new Terminal(pMsg->getTerminalId());
• break;
• case DELETE_TERMINAL:
• delete terminals[pMsg->getTerminalId()];
• break;
• case RUN_DIAGNOSTICS:
• status = terminals[pMsg->getTerminalId()]->handleRunDiagnostics();
• break;
• case PERFORM_SWITCHOVER:
• status1 = terminals[pMsg->getTerminalId1()]->handleOutOfService();
• status2 = terminals[pMsg->getTerminalId2()]->handleInService();
• break;
• }
• }
• };
Design Patterns
Exemplo
• Manager Design Pattern (cont 8/9)
– Sample Code and Usage
• class Terminal
• {
• TerminalId terminalId;
• public:
• Terminal(TerminalID terminalId);
• ~Terminal();
• Status handleRunDiagnostics();
• Status handleOutOfService();
• Status handleInService();
• };
Design Patterns
Exemplo
• Manager Design Pattern (cont 9/9)
– Known Uses
• The manager design pattern is used wherever there is a need to manage
multiple objects of same or similar behavior.
– Related Patterns
• Feature Design Patterns like parallel and serial coordination.
Design Patterns - Exercício
• Identificar e descrever os design patterns utilizados no
projeto, apresentando o racional de uso;
• Identificar e descrever a possibilidade de uso de design
patterns no projeto, defendendo o porque da escolha e os
impactos da mudança no projeto;
• Extra: identificar novos padrões (designs que podem ser
reutilizados em outros projetos) e descrevê-los de acordo com
o template apresentado anteriormente;
Universidade Positivo
Especialização em Engenharia de Software
Práticas de Desenvolvimento de Software
Tiago Barros | tiago@tiagobarros.org

Mais conteúdo relacionado

Mais procurados

Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Rosanete Grassiani dos Santos
 
Engenharia Requisitos - Método RON
Engenharia Requisitos - Método RONEngenharia Requisitos - Método RON
Engenharia Requisitos - Método RON
Eduardo Castro
 
Rastreabilidade de Requisitos
Rastreabilidade de RequisitosRastreabilidade de Requisitos
Rastreabilidade de Requisitos
transparenciadesoftware
 
Eng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. RequisitosEng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. Requisitos
Manuel Menezes de Sequeira
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
Tamires Guedes
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
Luís Fernando Richter
 
Engenharia de software
Engenharia de softwareEngenharia de software
Engenharia de software
Joao Johanes
 
02 Introdução à engenharia de software - conceitos fundamentais
02 Introdução à engenharia de software - conceitos fundamentais02 Introdução à engenharia de software - conceitos fundamentais
02 Introdução à engenharia de software - conceitos fundamentais
Waldemar Roberti
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de Software
Ralph Rassweiler
 
Gerência de Requisitos
Gerência de RequisitosGerência de Requisitos
Gerência de Requisitos
Mauricio Volkweis Astiazara
 
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Danielle Ballester, PMP,PSM,SFC,SDC,SMC,SPOC,SCT
 
Engenharia de software i 3 - processos de engenharia de requisitos
Engenharia de software i   3 - processos de engenharia de requisitosEngenharia de software i   3 - processos de engenharia de requisitos
Engenharia de software i 3 - processos de engenharia de requisitos
Willian Moreira Figueiredo de Souza
 
Prototipação
PrototipaçãoPrototipação
Prototipação
Daniel Fernandes
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
elliando dias
 
[CEFETMG][ESw] Aula 2 - Processos de software
[CEFETMG][ESw] Aula 2 - Processos de software[CEFETMG][ESw] Aula 2 - Processos de software
[CEFETMG][ESw] Aula 2 - Processos de software
Universidade Federal de Minas Gerais
 
Definição e classificação dos requisitos
Definição e classificação dos requisitosDefinição e classificação dos requisitos
Definição e classificação dos requisitos
ETEIT - Escola Técnica da Univale
 
Engenharia De Software Baseada Em Componentes
Engenharia De Software Baseada Em ComponentesEngenharia De Software Baseada Em Componentes
Engenharia De Software Baseada Em Componentes
igordsm
 
Eng.ª do Software - 10. Testes de software
Eng.ª do Software - 10. Testes de softwareEng.ª do Software - 10. Testes de software
Eng.ª do Software - 10. Testes de software
Manuel Menezes de Sequeira
 
Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01
Danielle Ballester, PMP,PSM,SFC,SDC,SMC,SPOC,SCT
 
Aula4 levantamento requisitos
Aula4 levantamento requisitosAula4 levantamento requisitos
Aula4 levantamento requisitos
Computação Depressão
 

Mais procurados (20)

Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
 
Engenharia Requisitos - Método RON
Engenharia Requisitos - Método RONEngenharia Requisitos - Método RON
Engenharia Requisitos - Método RON
 
Rastreabilidade de Requisitos
Rastreabilidade de RequisitosRastreabilidade de Requisitos
Rastreabilidade de Requisitos
 
Eng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. RequisitosEng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. Requisitos
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
 
Engenharia de software
Engenharia de softwareEngenharia de software
Engenharia de software
 
02 Introdução à engenharia de software - conceitos fundamentais
02 Introdução à engenharia de software - conceitos fundamentais02 Introdução à engenharia de software - conceitos fundamentais
02 Introdução à engenharia de software - conceitos fundamentais
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de Software
 
Gerência de Requisitos
Gerência de RequisitosGerência de Requisitos
Gerência de Requisitos
 
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
 
Engenharia de software i 3 - processos de engenharia de requisitos
Engenharia de software i   3 - processos de engenharia de requisitosEngenharia de software i   3 - processos de engenharia de requisitos
Engenharia de software i 3 - processos de engenharia de requisitos
 
Prototipação
PrototipaçãoPrototipação
Prototipação
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
 
[CEFETMG][ESw] Aula 2 - Processos de software
[CEFETMG][ESw] Aula 2 - Processos de software[CEFETMG][ESw] Aula 2 - Processos de software
[CEFETMG][ESw] Aula 2 - Processos de software
 
Definição e classificação dos requisitos
Definição e classificação dos requisitosDefinição e classificação dos requisitos
Definição e classificação dos requisitos
 
Engenharia De Software Baseada Em Componentes
Engenharia De Software Baseada Em ComponentesEngenharia De Software Baseada Em Componentes
Engenharia De Software Baseada Em Componentes
 
Eng.ª do Software - 10. Testes de software
Eng.ª do Software - 10. Testes de softwareEng.ª do Software - 10. Testes de software
Eng.ª do Software - 10. Testes de software
 
Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01
 
Aula4 levantamento requisitos
Aula4 levantamento requisitosAula4 levantamento requisitos
Aula4 levantamento requisitos
 

Destaque

Interfaces fisicas para dispositivos moveis
Interfaces fisicas para dispositivos moveisInterfaces fisicas para dispositivos moveis
Interfaces fisicas para dispositivos moveis
Tiago Barros
 
Técnicas de Prototipação II - Physical Computing - Aula 02
Técnicas de Prototipação II - Physical Computing - Aula 02Técnicas de Prototipação II - Physical Computing - Aula 02
Técnicas de Prototipação II - Physical Computing - Aula 02
Tiago Barros
 
O que falta na internet para as coisas?
O que falta na internet para as coisas?O que falta na internet para as coisas?
O que falta na internet para as coisas?
Tiago Barros
 
C.E.S.A.R Introducao ao Arduino
C.E.S.A.R Introducao ao ArduinoC.E.S.A.R Introducao ao Arduino
C.E.S.A.R Introducao ao Arduino
Tiago Barros
 
Introdução a Internet das Coisas
Introdução a Internet das CoisasIntrodução a Internet das Coisas
Introdução a Internet das Coisas
Tiago Barros
 
Curso de Arduino Completo
Curso de Arduino CompletoCurso de Arduino Completo
Curso de Arduino Completo
Tiago Barros
 
Técnicas de Prototipação II - Physical Computing - Aula 03
Técnicas de Prototipação II - Physical Computing - Aula 03Técnicas de Prototipação II - Physical Computing - Aula 03
Técnicas de Prototipação II - Physical Computing - Aula 03
Tiago Barros
 
Técnicas de Prototipação II - LEGO Aula 03
Técnicas de Prototipação II - LEGO Aula 03Técnicas de Prototipação II - LEGO Aula 03
Técnicas de Prototipação II - LEGO Aula 03
Tiago Barros
 
C.E.S.A.R - Prototipación Electronica en Diseño
C.E.S.A.R - Prototipación Electronica en DiseñoC.E.S.A.R - Prototipación Electronica en Diseño
C.E.S.A.R - Prototipación Electronica en Diseño
Tiago Barros
 
Técnicas de Prototipação II - LEGO Aula 01
Técnicas de Prototipação II - LEGO Aula 01Técnicas de Prototipação II - LEGO Aula 01
Técnicas de Prototipação II - LEGO Aula 01
Tiago Barros
 
Técnicas de Prototipação II - LEGO Aula 04
Técnicas de Prototipação II - LEGO Aula 04Técnicas de Prototipação II - LEGO Aula 04
Técnicas de Prototipação II - LEGO Aula 04
Tiago Barros
 
Técnicas de Prototipação II - LEGO Aula 02
Técnicas de Prototipação II - LEGO Aula 02Técnicas de Prototipação II - LEGO Aula 02
Técnicas de Prototipação II - LEGO Aula 02
Tiago Barros
 
Técnicas de Prototipação II - Physical Computing - Aula 01
Técnicas de Prototipação II - Physical Computing - Aula 01Técnicas de Prototipação II - Physical Computing - Aula 01
Técnicas de Prototipação II - Physical Computing - Aula 01
Tiago Barros
 
Mercado de automação no ES
Mercado de automação no ESMercado de automação no ES
Mercado de automação no ES
Felipe Martins
 
Modelagem e Controle de Robôs Móveis e Sistemas Multirrobôs
Modelagem e Controle de Robôs Móveis e Sistemas MultirrobôsModelagem e Controle de Robôs Móveis e Sistemas Multirrobôs
Modelagem e Controle de Robôs Móveis e Sistemas Multirrobôs
Felipe Martins
 
Aprender e ensinar com tecnologias móveis: um desafio para professores e alunos
Aprender e ensinar com tecnologias móveis: um desafio para professores e alunosAprender e ensinar com tecnologias móveis: um desafio para professores e alunos
Aprender e ensinar com tecnologias móveis: um desafio para professores e alunos
GILT (Games, Interaction and Learning Technologies) IS Engenharia do Porto
 
Javascript, Done Right
Javascript, Done RightJavascript, Done Right
Javascript, Done Right
André Luís
 
Competições Estudantis de Rrobótica
Competições Estudantis de RrobóticaCompetições Estudantis de Rrobótica
Competições Estudantis de Rrobótica
Felipe Martins
 
JavaScript for Beginners
JavaScript for BeginnersJavaScript for Beginners
JavaScript for Beginners
SAPO Sessions
 
Introdução ao Controle de Robôs Móveis
Introdução ao Controle de Robôs MóveisIntrodução ao Controle de Robôs Móveis
Introdução ao Controle de Robôs Móveis
Felipe Martins
 

Destaque (20)

Interfaces fisicas para dispositivos moveis
Interfaces fisicas para dispositivos moveisInterfaces fisicas para dispositivos moveis
Interfaces fisicas para dispositivos moveis
 
Técnicas de Prototipação II - Physical Computing - Aula 02
Técnicas de Prototipação II - Physical Computing - Aula 02Técnicas de Prototipação II - Physical Computing - Aula 02
Técnicas de Prototipação II - Physical Computing - Aula 02
 
O que falta na internet para as coisas?
O que falta na internet para as coisas?O que falta na internet para as coisas?
O que falta na internet para as coisas?
 
C.E.S.A.R Introducao ao Arduino
C.E.S.A.R Introducao ao ArduinoC.E.S.A.R Introducao ao Arduino
C.E.S.A.R Introducao ao Arduino
 
Introdução a Internet das Coisas
Introdução a Internet das CoisasIntrodução a Internet das Coisas
Introdução a Internet das Coisas
 
Curso de Arduino Completo
Curso de Arduino CompletoCurso de Arduino Completo
Curso de Arduino Completo
 
Técnicas de Prototipação II - Physical Computing - Aula 03
Técnicas de Prototipação II - Physical Computing - Aula 03Técnicas de Prototipação II - Physical Computing - Aula 03
Técnicas de Prototipação II - Physical Computing - Aula 03
 
Técnicas de Prototipação II - LEGO Aula 03
Técnicas de Prototipação II - LEGO Aula 03Técnicas de Prototipação II - LEGO Aula 03
Técnicas de Prototipação II - LEGO Aula 03
 
C.E.S.A.R - Prototipación Electronica en Diseño
C.E.S.A.R - Prototipación Electronica en DiseñoC.E.S.A.R - Prototipación Electronica en Diseño
C.E.S.A.R - Prototipación Electronica en Diseño
 
Técnicas de Prototipação II - LEGO Aula 01
Técnicas de Prototipação II - LEGO Aula 01Técnicas de Prototipação II - LEGO Aula 01
Técnicas de Prototipação II - LEGO Aula 01
 
Técnicas de Prototipação II - LEGO Aula 04
Técnicas de Prototipação II - LEGO Aula 04Técnicas de Prototipação II - LEGO Aula 04
Técnicas de Prototipação II - LEGO Aula 04
 
Técnicas de Prototipação II - LEGO Aula 02
Técnicas de Prototipação II - LEGO Aula 02Técnicas de Prototipação II - LEGO Aula 02
Técnicas de Prototipação II - LEGO Aula 02
 
Técnicas de Prototipação II - Physical Computing - Aula 01
Técnicas de Prototipação II - Physical Computing - Aula 01Técnicas de Prototipação II - Physical Computing - Aula 01
Técnicas de Prototipação II - Physical Computing - Aula 01
 
Mercado de automação no ES
Mercado de automação no ESMercado de automação no ES
Mercado de automação no ES
 
Modelagem e Controle de Robôs Móveis e Sistemas Multirrobôs
Modelagem e Controle de Robôs Móveis e Sistemas MultirrobôsModelagem e Controle de Robôs Móveis e Sistemas Multirrobôs
Modelagem e Controle de Robôs Móveis e Sistemas Multirrobôs
 
Aprender e ensinar com tecnologias móveis: um desafio para professores e alunos
Aprender e ensinar com tecnologias móveis: um desafio para professores e alunosAprender e ensinar com tecnologias móveis: um desafio para professores e alunos
Aprender e ensinar com tecnologias móveis: um desafio para professores e alunos
 
Javascript, Done Right
Javascript, Done RightJavascript, Done Right
Javascript, Done Right
 
Competições Estudantis de Rrobótica
Competições Estudantis de RrobóticaCompetições Estudantis de Rrobótica
Competições Estudantis de Rrobótica
 
JavaScript for Beginners
JavaScript for BeginnersJavaScript for Beginners
JavaScript for Beginners
 
Introdução ao Controle de Robôs Móveis
Introdução ao Controle de Robôs MóveisIntrodução ao Controle de Robôs Móveis
Introdução ao Controle de Robôs Móveis
 

Semelhante a Práticas de Desenvolvimento de Software

Sonarqube
SonarqubeSonarqube
Sonarqube
CDS
 
SonarQube
SonarQubeSonarQube
SonarQube
CDS
 
Apresentação RUP
Apresentação RUPApresentação RUP
Apresentação RUP
Fernando Nogueira
 
aula projeto e des sistemas 22 03 2021.pptx
aula projeto e des sistemas 22 03 2021.pptxaula projeto e des sistemas 22 03 2021.pptx
aula projeto e des sistemas 22 03 2021.pptx
MarcondesTiburcio
 
Processo e Processo de Software
Processo e Processo de SoftwareProcesso e Processo de Software
Processo e Processo de Software
Elaine Cecília Gatto
 
Aula 2 - Modelos de processos
Aula 2 -  Modelos de processosAula 2 -  Modelos de processos
Aula 2 - Modelos de processos
Leinylson Fontinele
 
347842.ppt
347842.ppt347842.ppt
347842.ppt
PedrinaBrasil2
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
wilsonguns
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
jamersonlima
 
Aula processo de reuso de software
Aula processo de reuso de softwareAula processo de reuso de software
Aula processo de reuso de software
Tatiana Tavares
 
A Carreira de Desenvolvedor: do Jr ao Sênior
A Carreira de Desenvolvedor: do Jr ao SêniorA Carreira de Desenvolvedor: do Jr ao Sênior
A Carreira de Desenvolvedor: do Jr ao Sênior
Marcos Pereira
 
Tendências e Dicas para o Desenvolvimento de Software
Tendências e Dicas para o Desenvolvimento de SoftwareTendências e Dicas para o Desenvolvimento de Software
Tendências e Dicas para o Desenvolvimento de Software
Norberto Santos
 
Csharp
CsharpCsharp
Áreas de Conhecimento da Engenharia de Software
Áreas de Conhecimento da Engenharia de SoftwareÁreas de Conhecimento da Engenharia de Software
Áreas de Conhecimento da Engenharia de Software
Elaine Cecília Gatto
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
CursoSENAC
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
Elaine Cecília Gatto
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
Igor Takenami
 
Técnicas_Implementação
Técnicas_ImplementaçãoTécnicas_Implementação
Técnicas_Implementação
Wagner Zaparoli
 
Aula1.pdf
Aula1.pdfAula1.pdf
TDC SP 2016 - Construindo um microserviço Java 100% funcional em 30 minutos
TDC SP 2016 - Construindo um microserviço Java 100% funcional em 30 minutosTDC SP 2016 - Construindo um microserviço Java 100% funcional em 30 minutos
TDC SP 2016 - Construindo um microserviço Java 100% funcional em 30 minutos
Rafael Chaves
 

Semelhante a Práticas de Desenvolvimento de Software (20)

Sonarqube
SonarqubeSonarqube
Sonarqube
 
SonarQube
SonarQubeSonarQube
SonarQube
 
Apresentação RUP
Apresentação RUPApresentação RUP
Apresentação RUP
 
aula projeto e des sistemas 22 03 2021.pptx
aula projeto e des sistemas 22 03 2021.pptxaula projeto e des sistemas 22 03 2021.pptx
aula projeto e des sistemas 22 03 2021.pptx
 
Processo e Processo de Software
Processo e Processo de SoftwareProcesso e Processo de Software
Processo e Processo de Software
 
Aula 2 - Modelos de processos
Aula 2 -  Modelos de processosAula 2 -  Modelos de processos
Aula 2 - Modelos de processos
 
347842.ppt
347842.ppt347842.ppt
347842.ppt
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Aula processo de reuso de software
Aula processo de reuso de softwareAula processo de reuso de software
Aula processo de reuso de software
 
A Carreira de Desenvolvedor: do Jr ao Sênior
A Carreira de Desenvolvedor: do Jr ao SêniorA Carreira de Desenvolvedor: do Jr ao Sênior
A Carreira de Desenvolvedor: do Jr ao Sênior
 
Tendências e Dicas para o Desenvolvimento de Software
Tendências e Dicas para o Desenvolvimento de SoftwareTendências e Dicas para o Desenvolvimento de Software
Tendências e Dicas para o Desenvolvimento de Software
 
Csharp
CsharpCsharp
Csharp
 
Áreas de Conhecimento da Engenharia de Software
Áreas de Conhecimento da Engenharia de SoftwareÁreas de Conhecimento da Engenharia de Software
Áreas de Conhecimento da Engenharia de Software
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
 
Técnicas_Implementação
Técnicas_ImplementaçãoTécnicas_Implementação
Técnicas_Implementação
 
Aula1.pdf
Aula1.pdfAula1.pdf
Aula1.pdf
 
TDC SP 2016 - Construindo um microserviço Java 100% funcional em 30 minutos
TDC SP 2016 - Construindo um microserviço Java 100% funcional em 30 minutosTDC SP 2016 - Construindo um microserviço Java 100% funcional em 30 minutos
TDC SP 2016 - Construindo um microserviço Java 100% funcional em 30 minutos
 

Mais de Tiago Barros

Introdução a Internet das Coisas
Introdução a Internet das CoisasIntrodução a Internet das Coisas
Introdução a Internet das Coisas
Tiago Barros
 
REC'n'Play 2019 - Aplicações industriais de internet das coisas: nem tudo é o...
REC'n'Play 2019 - Aplicações industriais de internet das coisas: nem tudo é o...REC'n'Play 2019 - Aplicações industriais de internet das coisas: nem tudo é o...
REC'n'Play 2019 - Aplicações industriais de internet das coisas: nem tudo é o...
Tiago Barros
 
KNoT - a framework for iot interoperability
KNoT - a framework for iot interoperabilityKNoT - a framework for iot interoperability
KNoT - a framework for iot interoperability
Tiago Barros
 
Providing Infrastructure to Enable IoT Solutions
Providing Infrastructure to Enable IoT SolutionsProviding Infrastructure to Enable IoT Solutions
Providing Infrastructure to Enable IoT Solutions
Tiago Barros
 
IEEE IoT Open Standards Committee
IEEE IoT Open Standards CommitteeIEEE IoT Open Standards Committee
IEEE IoT Open Standards Committee
Tiago Barros
 
CESAR School - Prototipação Eletrônica com Arduino
CESAR School - Prototipação Eletrônica com ArduinoCESAR School - Prototipação Eletrônica com Arduino
CESAR School - Prototipação Eletrônica com Arduino
Tiago Barros
 
KNoT Manifesto
KNoT ManifestoKNoT Manifesto
KNoT Manifesto
Tiago Barros
 
KNoT - Uma plataforma de IoT interoperável para o Brasil
KNoT - Uma plataforma de IoT interoperável para o BrasilKNoT - Uma plataforma de IoT interoperável para o Brasil
KNoT - Uma plataforma de IoT interoperável para o Brasil
Tiago Barros
 
Técnicas de Prototipação II - LEGO Aula 05
Técnicas de Prototipação II - LEGO Aula 05Técnicas de Prototipação II - LEGO Aula 05
Técnicas de Prototipação II - LEGO Aula 05
Tiago Barros
 

Mais de Tiago Barros (9)

Introdução a Internet das Coisas
Introdução a Internet das CoisasIntrodução a Internet das Coisas
Introdução a Internet das Coisas
 
REC'n'Play 2019 - Aplicações industriais de internet das coisas: nem tudo é o...
REC'n'Play 2019 - Aplicações industriais de internet das coisas: nem tudo é o...REC'n'Play 2019 - Aplicações industriais de internet das coisas: nem tudo é o...
REC'n'Play 2019 - Aplicações industriais de internet das coisas: nem tudo é o...
 
KNoT - a framework for iot interoperability
KNoT - a framework for iot interoperabilityKNoT - a framework for iot interoperability
KNoT - a framework for iot interoperability
 
Providing Infrastructure to Enable IoT Solutions
Providing Infrastructure to Enable IoT SolutionsProviding Infrastructure to Enable IoT Solutions
Providing Infrastructure to Enable IoT Solutions
 
IEEE IoT Open Standards Committee
IEEE IoT Open Standards CommitteeIEEE IoT Open Standards Committee
IEEE IoT Open Standards Committee
 
CESAR School - Prototipação Eletrônica com Arduino
CESAR School - Prototipação Eletrônica com ArduinoCESAR School - Prototipação Eletrônica com Arduino
CESAR School - Prototipação Eletrônica com Arduino
 
KNoT Manifesto
KNoT ManifestoKNoT Manifesto
KNoT Manifesto
 
KNoT - Uma plataforma de IoT interoperável para o Brasil
KNoT - Uma plataforma de IoT interoperável para o BrasilKNoT - Uma plataforma de IoT interoperável para o Brasil
KNoT - Uma plataforma de IoT interoperável para o Brasil
 
Técnicas de Prototipação II - LEGO Aula 05
Técnicas de Prototipação II - LEGO Aula 05Técnicas de Prototipação II - LEGO Aula 05
Técnicas de Prototipação II - LEGO Aula 05
 

Último

Reino-Vegetal plantas e demais conceitos .pptx
Reino-Vegetal plantas e demais conceitos .pptxReino-Vegetal plantas e demais conceitos .pptx
Reino-Vegetal plantas e demais conceitos .pptx
CarinaSantos916505
 
Aula 2 - Revisando o significado de fração - Parte 2.pptx
Aula 2 - Revisando o significado de fração - Parte 2.pptxAula 2 - Revisando o significado de fração - Parte 2.pptx
Aula 2 - Revisando o significado de fração - Parte 2.pptx
LILIANPRESTESSCUDELE
 
Fernão Lopes. pptx
Fernão Lopes.                       pptxFernão Lopes.                       pptx
Fernão Lopes. pptx
TomasSousa7
 
Vogais Ilustrados para alfabetização infantil
Vogais Ilustrados para alfabetização infantilVogais Ilustrados para alfabetização infantil
Vogais Ilustrados para alfabetização infantil
mamaeieby
 
D20 - Descritores SAEB de Língua Portuguesa
D20 - Descritores SAEB de Língua PortuguesaD20 - Descritores SAEB de Língua Portuguesa
D20 - Descritores SAEB de Língua Portuguesa
eaiprofpolly
 
Rimas, Luís Vaz de Camões. pptx
Rimas, Luís Vaz de Camões.          pptxRimas, Luís Vaz de Camões.          pptx
Rimas, Luís Vaz de Camões. pptx
TomasSousa7
 
O Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdf
O Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdfO Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdf
O Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdf
silvamelosilva300
 
Atividades de Inglês e Espanhol para Imprimir - Alfabetinho
Atividades de Inglês e Espanhol para Imprimir - AlfabetinhoAtividades de Inglês e Espanhol para Imprimir - Alfabetinho
Atividades de Inglês e Espanhol para Imprimir - Alfabetinho
MateusTavares54
 
Dicas de normas ABNT para trabalho de conclusão de curso
Dicas de normas ABNT para trabalho de conclusão de cursoDicas de normas ABNT para trabalho de conclusão de curso
Dicas de normas ABNT para trabalho de conclusão de curso
Simone399395
 
UFCD_10949_Lojas e-commerce no-code_índice.pdf
UFCD_10949_Lojas e-commerce no-code_índice.pdfUFCD_10949_Lojas e-commerce no-code_índice.pdf
UFCD_10949_Lojas e-commerce no-code_índice.pdf
Manuais Formação
 
347018542-PAULINA-CHIZIANE-Balada-de-Amor-ao-Vento-pdf.pdf
347018542-PAULINA-CHIZIANE-Balada-de-Amor-ao-Vento-pdf.pdf347018542-PAULINA-CHIZIANE-Balada-de-Amor-ao-Vento-pdf.pdf
347018542-PAULINA-CHIZIANE-Balada-de-Amor-ao-Vento-pdf.pdf
AntnioManuelAgdoma
 
Cartinhas de solidariedade e esperança.pptx
Cartinhas de solidariedade e esperança.pptxCartinhas de solidariedade e esperança.pptx
Cartinhas de solidariedade e esperança.pptx
Zenir Carmen Bez Trombeta
 
GÊNERO TEXTUAL - POEMA.pptx
GÊNERO      TEXTUAL     -     POEMA.pptxGÊNERO      TEXTUAL     -     POEMA.pptx
GÊNERO TEXTUAL - POEMA.pptx
Marlene Cunhada
 
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptx
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptxSlides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptx
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptx
LuizHenriquedeAlmeid6
 
OS elementos de uma boa Redação para o ENEM.pdf
OS elementos de uma boa Redação para o ENEM.pdfOS elementos de uma boa Redação para o ENEM.pdf
OS elementos de uma boa Redação para o ENEM.pdf
AmiltonAparecido1
 
1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.
1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.
1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.
LeticiaRochaCupaiol
 
PP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptx
PP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptxPP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptx
PP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptx
LuizHenriquedeAlmeid6
 
Atividade de reforço de matemática 2º ano
Atividade de reforço de matemática 2º anoAtividade de reforço de matemática 2º ano
Atividade de reforço de matemática 2º ano
fernandacosta37763
 
Educação trabalho HQ em sala de aula uma excelente ideia
Educação  trabalho HQ em sala de aula uma excelente  ideiaEducação  trabalho HQ em sala de aula uma excelente  ideia
Educação trabalho HQ em sala de aula uma excelente ideia
joseanesouza36
 
Leonardo da Vinci .pptx
Leonardo da Vinci                  .pptxLeonardo da Vinci                  .pptx
Leonardo da Vinci .pptx
TomasSousa7
 

Último (20)

Reino-Vegetal plantas e demais conceitos .pptx
Reino-Vegetal plantas e demais conceitos .pptxReino-Vegetal plantas e demais conceitos .pptx
Reino-Vegetal plantas e demais conceitos .pptx
 
Aula 2 - Revisando o significado de fração - Parte 2.pptx
Aula 2 - Revisando o significado de fração - Parte 2.pptxAula 2 - Revisando o significado de fração - Parte 2.pptx
Aula 2 - Revisando o significado de fração - Parte 2.pptx
 
Fernão Lopes. pptx
Fernão Lopes.                       pptxFernão Lopes.                       pptx
Fernão Lopes. pptx
 
Vogais Ilustrados para alfabetização infantil
Vogais Ilustrados para alfabetização infantilVogais Ilustrados para alfabetização infantil
Vogais Ilustrados para alfabetização infantil
 
D20 - Descritores SAEB de Língua Portuguesa
D20 - Descritores SAEB de Língua PortuguesaD20 - Descritores SAEB de Língua Portuguesa
D20 - Descritores SAEB de Língua Portuguesa
 
Rimas, Luís Vaz de Camões. pptx
Rimas, Luís Vaz de Camões.          pptxRimas, Luís Vaz de Camões.          pptx
Rimas, Luís Vaz de Camões. pptx
 
O Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdf
O Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdfO Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdf
O Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdf
 
Atividades de Inglês e Espanhol para Imprimir - Alfabetinho
Atividades de Inglês e Espanhol para Imprimir - AlfabetinhoAtividades de Inglês e Espanhol para Imprimir - Alfabetinho
Atividades de Inglês e Espanhol para Imprimir - Alfabetinho
 
Dicas de normas ABNT para trabalho de conclusão de curso
Dicas de normas ABNT para trabalho de conclusão de cursoDicas de normas ABNT para trabalho de conclusão de curso
Dicas de normas ABNT para trabalho de conclusão de curso
 
UFCD_10949_Lojas e-commerce no-code_índice.pdf
UFCD_10949_Lojas e-commerce no-code_índice.pdfUFCD_10949_Lojas e-commerce no-code_índice.pdf
UFCD_10949_Lojas e-commerce no-code_índice.pdf
 
347018542-PAULINA-CHIZIANE-Balada-de-Amor-ao-Vento-pdf.pdf
347018542-PAULINA-CHIZIANE-Balada-de-Amor-ao-Vento-pdf.pdf347018542-PAULINA-CHIZIANE-Balada-de-Amor-ao-Vento-pdf.pdf
347018542-PAULINA-CHIZIANE-Balada-de-Amor-ao-Vento-pdf.pdf
 
Cartinhas de solidariedade e esperança.pptx
Cartinhas de solidariedade e esperança.pptxCartinhas de solidariedade e esperança.pptx
Cartinhas de solidariedade e esperança.pptx
 
GÊNERO TEXTUAL - POEMA.pptx
GÊNERO      TEXTUAL     -     POEMA.pptxGÊNERO      TEXTUAL     -     POEMA.pptx
GÊNERO TEXTUAL - POEMA.pptx
 
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptx
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptxSlides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptx
Slides Lição 11, Central Gospel, Os Mortos Em CRISTO, 2Tr24.pptx
 
OS elementos de uma boa Redação para o ENEM.pdf
OS elementos de uma boa Redação para o ENEM.pdfOS elementos de uma boa Redação para o ENEM.pdf
OS elementos de uma boa Redação para o ENEM.pdf
 
1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.
1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.
1ª LEI DE OHN, CARACTERISTICAS IMPORTANTES.
 
PP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptx
PP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptxPP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptx
PP Slides Lição 11, Betel, Ordenança para exercer a fé, 2Tr24.pptx
 
Atividade de reforço de matemática 2º ano
Atividade de reforço de matemática 2º anoAtividade de reforço de matemática 2º ano
Atividade de reforço de matemática 2º ano
 
Educação trabalho HQ em sala de aula uma excelente ideia
Educação  trabalho HQ em sala de aula uma excelente  ideiaEducação  trabalho HQ em sala de aula uma excelente  ideia
Educação trabalho HQ em sala de aula uma excelente ideia
 
Leonardo da Vinci .pptx
Leonardo da Vinci                  .pptxLeonardo da Vinci                  .pptx
Leonardo da Vinci .pptx
 

Práticas de Desenvolvimento de Software

  • 1. Universidade Positivo Especialização em Engenharia de Software Práticas de Desenvolvimento de Software Tiago Barros | tiago@tiagobarros.org
  • 2. Conteúdo do curso • Construção de software – O que é construção de software – Construção de software dentro de um processo de desenvolvimento • Paradigmas de programação e a construção de software – Paradigmas de linguagens de programação – Compilação e execução de programas – Alocação de memória
  • 3. Conteúdo do curso • Arquiteturas de software • Introdução aos Padrões de Projeto • Tipos de Padrões de projeto – Criacionais – Arquiteturais – Comportamentais • Documentação de padrões de projeto
  • 4. Avaliação • Exercícios realizados em sala • Identificação e documentação da aplicação de técnicas de reengenharia, reuso e padrões no projeto de desenvolvimento de software. • Apresentação das mudanças na arquitetura, com seus benefícios e custos.
  • 5. Bibliografia • Code Complete: A Practical Handbook of Software Construction. Steve McConnell. • Design Patterns: Elements of Reusable Object-Oriented Software. Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides. • The Pragmatic Programmer: From Journeyman to Master. Andrew Hunt, David Thomas. • Software Engineering. Ian Sommerville. • C.R.U.I.S.E – Component Reuse In Software Engineering. Eduardo Almeida, Alexandre Alvaro, Vinicius Garcia, Jorge Mascena, Vanilson Burégio, Leandro Nascimento, Daniel Lucrédio, Silvio Meira.
  • 6. Práticas de Desenvolvimento de Software Construção de Software Tiago Barros | tiago@tiagobarros.org
  • 7. Construção de Software • A etapa de construção consiste na parte “mão na massa” da criação de alguma coisa • Inclui alguns aspectos de planejamento, projeto e verificação, mas é essencialmente execução • Quais as fases de um projeto de software que fazem parte da construção de software?
  • 8. Construção de Software Figura retirada do livro Code Complete
  • 9. Construção de Software Figura retirada do livro Code Complete
  • 10. Construção de Software O que significa “codificar e debugar”?
  • 11. Construção de Software • O que significa “codificar e debugar”? • Projetar e codificar classes e funções • Criar e nomear variáveis e tipos de dados corretamente • Definir as estruturas de controle • Fazer testes unitários e debugar o próprio código • Fazer revisão de código • Formatar e comentar o código • Selecionar e integrar os componetes de software utilizados • Otimizar o código
  • 12. Construção de Software Porque construção de software é importante?
  • 13. Construção de Software • Porque construção de software é importante? • É uma grande parte do processo de desenvolvimento de software • É a parte central do processo de desenvolvimento de software • Foco na construção aumenta a produtividade • A construção de software é a única atividade que é garantida de acontecer e ser entregue em todo projeto
  • 14. Construção de Software Pontos chave • Construção de software é a parte que o cliente realmente compra • A qualidade da construção afeta diretamente a qualidade do software • As principais atividades da construção são: design detalhado, codificação, depuração e testes unitários e de integração.
  • 15. Práticas de Desenvolvimento de Software Paradigmas de Programação Tiago Barros | tiago@tiagobarros.org
  • 16. Construção de Software O que é uma linguagem de programação?
  • 17. Paradigmas de Programação • O que é uma linguagem de programação? – Conjunto de expressões, com regras sintáticas e semânticas, para expressar um programa de computador – __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________
  • 18. Construção de Software O que é um paradigma de programação?
  • 19. Paradigmas de Programação • O que é um paradigma de programação? – Modelo de programação suportado por linguagens que agrupam certas características em comum – Impactam na forma como um problema real é modelado computacionalmente – __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________
  • 20. Paradigmas de Programação • Paradigma Imperativo – É definido como uma sequência de comandos (ordens) que modificam o estado (variáveis) de um programa, de acordo com os dados de entrada, para produzir uma determinada saída. PROGRAMA Comando... Comando... Comando... DADOS (estado) ENTRADA SAÍDA
  • 21. Paradigmas de Programação • Paradigma Imperativo – Vantagens • Modelagem natural de aplicações do mundo real • Eficiência (diretamente implementado pelos processadores) • Bem estabelecido (dominante) – Desvantagens • Difícil legibilidade • Problemas de manutenção, principalmente em grandes sistemas
  • 22. • Paradigma Orientado a Objetos – Define uma aplicação como um conjunto de módulos (objetos que são representados por classes), que possuem um estado (variáveis) e operações que modificam este estado (métodos). – É uma subclassificação do paradigma imperativo (não é uma classificação de paradigma) Paradigmas de Programação CLASSE Operação... Operação... Operação... DADOS (estado) ENTRADA SAÍDA CLASSE Operação... Operação... Operação... DADOS (estado) ENTRADA SAÍDA CLASSE Operação... Operação... Operação... DADOS (estado) ENTRADA SAÍDA
  • 23. Paradigmas de Programação • Paradigma Orientado a Objetos – Vantagens • Modelagem natural de aplicações do mundo real • Eficiência (diretamente implementado pelos processadores) • Classes são abstrações auto-contidas de elementos do mundo real (tipos complexos) • Modularidade • Reusabilidade • Extensibilidade • Bem estabelecido – Desvantagens • Semelhantes ao imperativo, mas amenizadas pela maior estruturação do programa.
  • 24. • Paradigma Funcional – Define um programa como um conjunto de funções que fazem o mapeamento dos valores de entrada em valores de saída, sem o conceito de estado do paradigma imperativo. – Funções são tratadas como valores e cada função é declarada em termos de outras funções (programação declarativa). Paradigmas de Programação PROGRAMA (função) ENTRADA SAÍDA
  • 25. Paradigmas de Programação • Paradigma Funcional – Vantagens • Manipulação de programas mais simples (prototipação) • Prova de propriedades • Transformação (otimização) – Desvantagens • Difícil mapeamento do mundo real na linguagem de programação • Baixa eficiência devido à dificuldade da implementação nos processadores • Entrada e saída (formatação, tela, etc) possuem apens mecanismos primitivos
  • 26. • Paradigma Lógico – Define um programa que formará conclusões a partir de um conjunto de premissas (declarações). – Possui um conjunto de fatos (declarações verdadeiras) e regras (manipulação) que descrevem o domínio do problema a resolver. Paradigmas de Programação PROGRAMA (fatos, regras) ENTRADA SAÍDA
  • 27. Paradigmas de Programação • Paradigma Lógico – Vantagens • Acumulam as mesmas vantagens do paradigma funcional • Permite a concepção de aplicações em um alto nível de abstração (através de associações de entrada e saída) – Desvantagens • Acumulam as mesmas desvantagens do paradigma funcional • Usualmente não possuem tipos nem funções de alta ordem
  • 28. Práticas de Desenvolvimento de Software Conceitos Básicos de Desenvolvimento Tiago Barros | tiago@tiagobarros.org
  • 29. Conceitos Básicos  Como funciona um compilador  Como funciona a execução de um programa  Variáveis e tipos de dados
  • 30. Conceitos Básicos Objetivos • Entendimento de como um programa é compilado e executado, no paradigma imperativo/orientado a objetos • Entendimento de como funciona a execução de um programa • Entendimento de como funcionam elementos básicos de um programa
  • 31. Conceitos Básicos • Compilação em C/C++ – Arquivo fonte (.c / .cpp) • Possui a implementação do código • É compilado – Arquivo de cabeçalho (.h) • Possui a declaração dos símbolos – Funções e variáveis • Não é compilado
  • 32. Conceitos Básicos • Compilação em C/C++ – Arquivo fonte (.c / .cpp) • O que não é encontrado, vai para a tabela de simbolos para ser resolvido na ligação (linker) • Cada arquivo fonte (.c / .cpp) gera um arquivo objeto (.o) – Arquivo de cabeçalho (.h) • É incluído no arquivo fonte para que o arquivo fonte “conheça” as declarações do cabeçalho
  • 33. Conceitos Básicos • Compilação em JAVA – Arquivo fonte (.java) • Possui a declaração e implementação da classe • Cada arquivo fonte (.java) gera um arquivo objeto (.class) • Os arquivos .class são “executados” (interpretados) pela máquina virtual
  • 34. Conceitos Básicos • Como Funciona um compilador – Instruções • Operação realizada por um processador • Linguagem fonte • Código intermediário • Código de máquina
  • 35. Conceitos Básicos • Como Funciona um compilador – Pré-processamento • Substituição de termos (macros) • Ativação de funcionalidades do compilador • Compilação condicional #include #define #pragma #if / #ifdef / #else / #endif
  • 36. Conceitos Básicos • Como Funciona um compilador – Compilação • Transformar código fonte em código objeto • Diferentes formatos de código objeto (dependente da máquina) • Código objeto pode ser diretamente executável
  • 37. Conceitos Básicos • Como Funciona um compilador – Compilação > Erros: • Definição de símbolos errada • Falta de definição de símbolos • Tipos de dados incompatíveis (impossível converter diretamente) • _________________________________ • _________________________________ • _________________________________ • _________________________________
  • 38. Conceitos Básicos • Como Funciona um compilador – Ligação • Juntar um ou mais códigos objeto e gerar um arquivo executável • Tabela de símbolos – Exportados – Importados
  • 39. Conceitos Básicos • Como Funciona um compilador – Ligação > Erros • Símbolos não existem • _________________________________ • _________________________________ • _________________________________ • _________________________________ • _________________________________ • _________________________________
  • 40. Conceitos Básicos • Compilação dinâmica (nativa) em Java – Código 100% interpretado chega a ser 10x mais lento que código compilado – Mas... – Código compilado é 4 a 5 x maior que código interpretado – Tradeoff entre performance e tamanho do código final
  • 41. Conceitos Básicos • Compilação dinâmica (nativa) em Java – Utilizar compilação adaptativa • Compila os métodos considerados “hot spots” para código nativo • Mantêm o restante como bytecode • Aumenta o uso de memória, mas também aumenta a performance
  • 42. Conceitos Básicos • Como Funciona a execução de um programa – Memória • Armazenamento • Programas e dados Address Data 0x00000000 0101100100110011 0x00000001 0001000110011110 0x00000002 1110010101010111 … … 0x00FD347B 0001010110110101 … … 0xFFFFFFFF 0011010101110110
  • 43. Conceitos Básicos • Como Funciona a execução de um programa – Unidade de processamento • Carregar e decodificar instruções • Controlar unidade de execução PC Decoder Memory Execution Unit
  • 44. Conceitos Básicos • Como Funciona a execução de um programa Registers MemoryALU
  • 45. Conceitos Básicos • Como Funciona a interpretação de uma classe Java – A VM recebe como parâmetro a classe a ser executada – A Classe é “carregada” na máquina virtual – O interpretador da VM procura o método main na classe – O interpretador inicia a execução do bytecode que está no método main • Caso a classe não tenha um método main, uma exceção é “jogada”
  • 46. Conceitos Básicos • Class loader  carrega cada uma das classes e verifica se as classes estão ok • Methods area  quando uma classe é carregada, os seus bytes codes são salvos nessa região • Heap  área de execução. Todos os objetos criados são colocados aqui • Java Stacks  pilhas de execução que guardam as chamadas dos métodos. Quando não existe mais nenhuma pilha, a VM é finalizada • Execution engine  interpretador do bytecode • Como Funciona a interpretação de uma classe Java
  • 47. Conceitos Básicos • Variáveis e tipos de dados – Tamanho do barramento de dados do processador (palavra) char int short long Ponteiro word c c c c short short int long pointer
  • 48. Áreas de memória de um programa Memória e tipos de dados Variáveis ponteiros Memória
  • 50. Memória • Áreas de armazenamento de variáveis de um programa – memória estática – pilha int g = 0; int main() { int x = 20; g = x; } ESTÁTICA 100 (g) 0 PILHA 200 (x) 20 20
  • 51. Memória • Áreas de armazenamento de variáveis de um programa – Heap int* g = NULL; int main() { int x = 20; g = (int*)malloc(sizeof(int)); *g = x; } ESTATICA 100 (g) 0x00000000 PILHA 200 (x) 20 0x00001000 HEAP 1000 ????????20
  • 52. Memória • Áreas de armazenamento de variáveis de um programa – Desalocando memória int* g = NULL; int main() { int x = 20; g = (int*)malloc(sizeof(int)); *g = x; free(g); } ESTÁTICA 100 (g) 0x00000000 PILHA 200 (x) 20 0x00001000 HEAP 1000 ????????20
  • 53. Memória • Variáveis ponteiros – Endereços de memória • O operador referência: & • O operador desreferência: * – Declarando ponteiros int i=10; int *intPtr; intPtr = &i;
  • 54. Memória • Variáveis ponteiros – O que significa: &i *i &intPtr *intPtr – Os operadores new e delete int *intPtr = new int; ... delete intPtr;
  • 55. Memória • Variáveis ponteiros int x = 10; char c = ‘c’; int* pi; char* pc = &c; int** ppi; int*** pppi; pc = “uma string”; pi = &x; ppi = π pppi = &ppi; ADDRESS DATA 0x00000100 (x) 10 0x00000104 (c) ‘c’ 0x00000108 (pi) 0x00000100 0x0000010C (pc) 0x00000104 0x00000110 (ppi) 0x00000108 0x00000114 (pppi) 0x00000110 .......................... .................... 0x00001100 “uma string” 0x0000110C 0x00001100
  • 56. Memória • Variáveis ponteiros – Exercício!  int global = 0; int inc(int* num) { return save(*num = *num + 1); } int save(int y) { global = y; } void main() { int *ptr = (int*)malloc(sizeof(int)); inc(ptr); printf(“%d”, *ptr); printf(“%d”, global); } 1. Descreva o que acontece com a memória do programa ao lado, conforme visto nos exemplos anteriores; 2. O programa ao lado compila? 3. Existe algum erro de execução no programa?
  • 57. Memória • Tipos de dados derivados – Arrays void main() { char array[] = “Hello!”; char *ptr = array; *ptr = ‘W’; ptr++; *ptr = ‘o’; ptr++; *ptr = ‘r’; ptr+= 2; *ptr = ‘d’; } PILHA 100 (array) H 101 e 102 l 103 l 104 o 105 ! 106 0 107 0x00000100108 (ptr) 10C W 0x000001010x00000102 o r d 0x00000104
  • 58. Memória • Tipos de dados derivados – Estruturas typedef struct __point { int x, y; } Point; void inc (Point q) { q.x++; q.y++; } void main() { Point p; p.x = 10; p.y = 20; inc(p); } PILHA p 100 (x) 104 (y) 10 20 q 108 (x) 10 10C (y) 20 11 21
  • 59. Memória • Tipos de dados derivados – Estruturas typedef struct __point { int x, y; } Point; void inc (Point* ptr) { p->x++; p->y++; } void main() { Point p; p.x = 10; p.y = 20; inc(&p); } PILHA p 100 (x) 104 (y) 108 (ptr) 0x00000100 10 20 11 21
  • 60. Memória • Tipos de dados derivados – Uniões #define B 0 #define G 1 #define R 2 #define A 3 #define MAX_COMP 4 typedef union __color { int value; char comp[MAX_COMP]; } Color; void main() { Color color; color.value = 0; color.comp[R] = 0xFF; } PILHA 3 2 1 0 100 (color) value comp 0 0 0 0255
  • 61. Memória em Java • A “carga” de uma classe java equivale a “carga” de um código nativo para ser executado. As classes ficam na “área de métodos” • Todo objeto criado em java é colocado na heap java (similar ao heap nativa) – No momento de executar a VM no PC é possível passar como parâmetro o tamanho máximo da heap java • Java não requer que o código “desaloque” explicitamente memória – A VM utiliza um “garbage collector” – Quando um objeto da heap não tem mais nenhum outro objeto apontando para ele, o coletor de lixo o remove da memória – É necessário então “limpar” referências que não são mais utilizadas (atribuir para null), caso contrário pode causar memory leak • Variáveis locais a um método são colocadas na pilha de java (similar a pilha nativa)
  • 62. Maquina Virtual JAVA • A HotSpot VM otimiza o gerenciamento de memória por idades (generational). • O heap da maquina virtual é dividida em young generation, old gereration e permanent generation de acordo com a idade do objeto
  • 63. Maquina Virtual JAVA • Na Young generation estão os objetos considerados com tempo curto relativo a um intervalo de coletas. • A young generation é dividida em 3 espacos : – um eden – dois espaços “Survivor”(to-space e from-space). – As alocações acontecem do eden para o from-space.Quando estes estão preenchidos a coleta na Young generation é feita. – Geralmente a young generation é muito menor em relação ao tamanho da heap.Isto leva a pequenas mas freqüentes pausas na young generation durante a execução do garbage collection.
  • 64. Maquina Virtual JAVA • Objetos que sobreviventes a um determinado numero de coletas são movidos(promovidos) para a old generation. • A old generation é tipicamente maior em relação a Young o que leva a pausas maiores e menos freqüentes . • A permanent generation é usada para armazenar classes de objetos e meta dados relacionados.
  • 66. Chamada de funções e mudança de contexto Passagem de parâmetros Ponteiros para funções Funções
  • 67. Funções • Declaração de funções tipo nome(argumentos...); • Corpo das funções tipo nome(argumentos...) { instruções; return expressão_de_retorno; }
  • 68. Funções • Chamada de funções / Pilha de execução int fib(int x) { int ret = 1; if (x > 1) ret = fib(x-1)+ fib(x-2); return ret; } void main() { int n = 3; n = fib(n); } PILHA 100 (n) 3 104 108 (x) 3 10C (ret) 1 1 110 114 (x) 2 118 (ret) 1 11C 120 (x) 1 124 (ret) 1 110 114 (x) 0 118 (ret) 1 1 2 2 3 3 3 110 114 (x) 1 118 (ret) 1 1
  • 69. Funções • Passagem de parâmetros / Retorno – Por valor • Variável é duplicada na pilha e seu valor é copiado • C / C++ / Java – Por referência • A referência (endereço) da variável é passada • C++
  • 70. Funções • Funções e arrays em C – Arrays como argumentos int add(int intArray[], int numElemnetos); int add(const int *intArray, int numElemnetos); – Arrays como retorno int * createArray(int numElementos)
  • 71. Funções • Funções e estruturas em C / C++ – Estruturas como argumento e retorno de funções: são passadas por valor (cópia) struct TBall{ int x, y;}; void move(TBall ball); TBall createBall(int x, int y); – Para evitar o overhead da cópia, costuma-se passar estruturas por referência constante: void move(const TBall &ball);
  • 72. Funções • Funções em Java (Métodos) – Java passa seus objetos como ponteiros! – Ponteiros são endereços passados por valor! class TBall { public int x, y; } class c1 { public void moveBall(TBall ball) { ball.x += 1; ball.y += 1; } public void createBall(TBall ball) { ball = new TBall(); } }
  • 73. Funções • Ponteiros para funções int funcao(int i); int (*ponteiro_para_funcao)(int i); ponteiro_para_funcao = funcao; int ret, arg; ret = (*ponteiro_para_funcao)(arg);
  • 74. Exercício • implementar um stream de dados na memória de acordo com os seguintes requisitos: – O stream deverá ter uma quantidade de memória previamente alocada e deverá prever casos de falta de memória, alocando mais se for preciso. – O stream de dados poderá armazenar dados dos seguintes tipos: char, short, int, long, float. – Deverá ser implementada um conjunto de funções para escrita e leitura de cada tipo de dados no stream. – O stream funcionará como uma fila FIFO, ou seja: o primeiro dado que for escrito será o primeiro dado a ser lido. – Cada tipo de dado inserido no stream deverá ocupar apenas a memória necessária (não deverá haver desperdício de memória, ou seja, alocação de memória a mais do que o necessário para armazenar o tipo de dado) – O usuário do stream é quem deverá se preocupar com a ordem de inserção / remoção de dados do stream, ou seja: se forem inseridos 2 int e depois tentar ler 2 char, deverão ser retornados os 2 primeiros bytes do primeiro int. – Deverão ser tratados os erros de falta de memória (na escrita do stream) e falta de dados (na leitura do stream)
  • 75. Exercício • Implementação em C – Implementar uma estrutura de dados para armazenar o stream e as seguintes funções para manipular esta estrutura: – void WriteChar(char c); – void WriteInt(int i); – void WriteShort(short s); – void WriteLong(long l); – void WriteFloat(float f); – char ReadChar(); – int ReadInt(); – short ReadShort(); – long ReadLong(); – float ReadFloat();
  • 76. Exercício • Implementação em C++ – Implementar a seguinte classe: class Stream { public: //construtor: initMemory é a mem inicial alocada Stream(int initMemory); // destrutor: libera toda memória utilizada ~Stream() // métodos de escrita no stream void WriteChar(char c); void WriteInt(int i); void WriteShort(short s); void WriteLong(long l); void WriteFloat(float f); // métodos de leitura do stream char ReadChar(); int ReadInt(); short ReadShort(); long ReadLong(); float ReadFloat(); private: // declare aqui todas as variáveis necessárias // para implementação deste código };
  • 77. Exercício • Testes – Implementar código de testes para testar o uso do stream, prevendo as situações de erro e verificando a completude do teste.
  • 78. Práticas de Desenvolvimento de Software Design de Software Tiago Barros | tiago@tiagobarros.org
  • 79. Design de Software • Processo de projetar um software • Concepção de um esquema para transformar a especificação em um software desenvolvido • O design de software é bastante útil em projetos pequenos e indispensável em projetos grandes • O design deve ser detalhado na quantidade de níveis necessária
  • 80. Design de Software Características de um bom Design • Minimização da complexidade • Facilidade de entendimento e manutenção • Baixo acoplamento • Estensibilidade • Reusabilidade • Portabilidade • Alto “fan-in” (várias classes usam uma classe) • Médio a baixo “fan-out” (uma classe usa poucas classes)
  • 81. Níveis de Design Figura retirada do livro Code Complete
  • 82. Arquitetura de Software • Design de software de alto nível • Abstração do sistema computacional em módulos (sub sistemas) • Com o crescimento dos sistemas computacionais, é preciso tomar decisões que vão além dos algoritmos e estruturas de dados utilizados
  • 83. Arquitetura de Software • A arquitetura de software trata de decisões sobre: – os componentes que formarão o sistema; – o papel que cada componente representará no sistema; – protocolos de comunicação entre os componentes; – formas de acesso a dados; – distribuição dos componentes do sistema; – atributos de qualidade do sistema (desempenho, escalabilidade, etc);
  • 84. Exercício • Seminário sobre arquiteturas de software – Apresentar e discutir os principais modelos de arquitetura utilizados no desenvolvimento de software; – Apresentar e discutir os modelos de arquitetura utilizados no projeto; (porque do uso, benefícios e custos) – Exemplos: • Arquitetura de repositório; • Arquitetura cliente-servidor; • Arquitetura em camadas; • Arquitetura orientada a serviços; • Arquitetura de objetos distribuídos; • etc.
  • 86. Design de Software • Rittel e Webber definem design como um problema cruel: a única forma de definir este problema é resolvendo o problema ou uma parte dele
  • 87. Design de Software Porque? • Design envolve restrições e trade offs • Design é não determinístico • Design é um processo heurístico
  • 88. Design de Software Entretanto... • Design pode ser capturado • Design é uma mistura de conhecimento e criatividade • Soluções de design que já foram resolvidas são reutilizadas, formam padrões Padrões de Projeto – Design Patterns
  • 89. Design de Software Então porque Design Patterns?
  • 90. Design de Software Então, porque Design Patterns? • Uma vez que definimos o problema através da sua resolução, podemos reusar esta resolução • Design Patterns permitem aos desenvolvedores compartilhar conhecimento sobre o design • São soluções de Design comprovadas para um determinado problema dado um contexto
  • 91. Práticas de Desenvolvimento de Software Design Patterns Tiago Barros | tiago@tiagobarros.org
  • 92. Design Patterns Histórico • Christopher Alexander (1970) – “Each pattern describes a problem that occurs over and over again in our environment and then describes the core of the solution to that problem in such a way that you can use this solution a million times over without ever doing it the same way twice.” • Patterns apareceram novamente na OOPSLA conference (1987). • Gamma, Helm, Johnson and Vlissides (the Gang of Four, or GoF) escreveram em conjunto o famoso livro: Design Patterns: Elements of Reusable Object-oriented Software.
  • 93. Design Patterns Conceitos • Patterns – Um padrão é uma forma completamente compreendida de um modelo aceito ou proposto para imitação… de acordo com o dicionário. – No nosso dia-a-dia encontramos vários problemas que já ocorreram e vão ocorrer de novo. Design Patterns nos permitem compartilhar a resolução destes problemas, que são bem conhecidos e já foram bem resolvidos.
  • 94. Design Patterns Conceitos • Anti-Patterns – Demosntram uma resolução errada, que deve ser evitada. – Descrevem como sair de um problema e como proceder para encontrar um solução adequada.
  • 95. Design Patterns Conceitos • Tipos de padrões – Padrões Arquiteturais • Descrevem a estrutura e o relacionamento entre os componentes de um software. – Padrões de Análise • Descrevem modelos cuja semântica os fazem aplicáveis a domínios de aplicação específicos. – Padrões de projeto • Identificam as relações internas de um grupo de componentes de software e descrevem a responsabilidade e colaboração entre eles. – Idiomas • Descrevem como implementar aspectos de sistemas de software em uma linguagem de programação específica.
  • 96. Design Patterns Conceitos • Design Patterns – “Descrição de objetos e classes que estão relacionados e customizados para resolver um problema de projeto, em um determinado contexto.“ – GoF define seus design patterns como: • “A design pattern names, abstracts, and identifies the key aspects of a common designstructure that make it useful for creating a reusable object-oriented design. The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities.”
  • 97. Design Patterns Aplicabilidade • Por que usar design patterns? – Foram provados. Patterns refletem a experiência, conhecimento e insights dos desenvolvedores que já utilizaram os padrões com sucesso em seu próprio código. – São reusáveis. Patterns proveem uma solução pronta que pode ser adaptada para diferentes problemas se necessário. – São expressivos. Patterns proveem um vocabulário comum de soluções que podem expressar soluções maiores de forma sucinta.
  • 98. Design Patterns Aplicabilidade • Quando usar um design pattern? • Responda as seguintes questões: • As consequencias do uso do padrão são aceitáveis? • Existe uma solução mais simples? • Existe algum padrão que ataca problemas similares? • Existe alguma restrição no uso do padrão? • Regras: • Preste atenção no contexto e no problema do padrão, verificando se o padrão é adequado e consistente com seu contexto. • Uso excessivo de padrões pode criar um projeto pesado. • Algumas pessoas acreditam que o uso de padrões pode limitar a criatividade do desenvolvedor.
  • 99. Design Patterns Aplicabilidade • Escrevendo padrões: um template – Pattern Name and Classification – Intent – Also Known As – Motivation – Applicability – Structure – Participants – Collaborations – Consequences – Implementation – Sample Code – Known Uses – Related Patterns
  • 100. Design Patterns Exemplo • Manager Design Pattern (from Realtime Mantra Pattern Catalog) – Intent • The main intention here is to manage multiple entities of same type. For example, a Terminal Manager will manage all the Terminal objects under its control. This will involve Terminal creation, Terminal deletion, message routing to the Terminal and coordination of activities like switchover between two Terminals. – Also Known As • Manager-Managed Design Pattern • Managed Object Design Pattern
  • 101. Design Patterns Exemplo • Manager Design Pattern cont(2/9) – Diagram Manager objectArray[] handleMessage(Message msg) Handles all messages to all objects that includes creation and deletion Array that holds the objects ManagedObject handleMsg1() handleMsg2() . . . Methods that handles each kind of message sent to object
  • 102. Design Patterns Exemplo • Manager Design Pattern (cont 3/9) – Motivation • Consider the case where no Manager object is defined. Each Terminal object has to know about all other Terminal objects for purposes of message routing and coordination. Also, in the absence of a Manager there will be no single point for Terminal object creation and deletion. – Applicability • This design pattern can be applied whenever a system needs to support many entities of same or similar type. The Manager object is designed to keep track of all the entities. In many cases, the Manager will also route messages to individual entities.
  • 103. Design Patterns Exemplo • Manager Design Pattern (cont 4/9) – Structure • The Manager object may manage all the entity objects by implementing standard data structures like array or STL map. The idea is to have a quick way of indexing to get to a particular entity. This indexing capability is required to quickly access an entity from a numerical id assigned to the entity. This numerical id will be typically included in all the messages received for these entities. – Participants • The Manager object and the Managed Entities are the main actors in this design pattern. A single Manager object manages multiple entity objects.
  • 104. Design Patterns Exemplo • Manager Design Pattern (cont 5/9) – Collaboration • Manager to Managed Entity communication is typically done via manager invoking methods for the individual entities. The return value of a method is used by the entity to communicate with the manager. The routing of messages is also achieved by invoking the message handler for the entity object. • In more complicated designs, the Manager and entity may communicate via local messages. In such cases, the various coordination design patterns like parallel and serial coordination may be used.
  • 105. Design Patterns Exemplo • Manager Design Pattern (cont 6/9) – Consequences • The Manager object introduces a clean interface for communicating with any of the managed entities. It also provides a centralized point for coordinating operations on multiple entity objects. – Implementation • As mentioned earlier, the Manager object contains an array or STL map of all the entities under its control. The entity collection may be maintained as pointers to the entity objects or entity objects themselves.
  • 106. Design Patterns Exemplo • Manager Design Pattern (cont 7/9) – Sample Code and Usage • class TerminalManager • { • Terminal* terminals[MAX_TERMINALS]; • public: • void handleMessage(Msg* pMsg) • { • switch (pMsg->getType()) • { • case CREATE_TERMINAL: • terminals[pMsg->getTerminalId()] = new Terminal(pMsg->getTerminalId()); • break; • case DELETE_TERMINAL: • delete terminals[pMsg->getTerminalId()]; • break; • case RUN_DIAGNOSTICS: • status = terminals[pMsg->getTerminalId()]->handleRunDiagnostics(); • break; • case PERFORM_SWITCHOVER: • status1 = terminals[pMsg->getTerminalId1()]->handleOutOfService(); • status2 = terminals[pMsg->getTerminalId2()]->handleInService(); • break; • } • } • };
  • 107. Design Patterns Exemplo • Manager Design Pattern (cont 8/9) – Sample Code and Usage • class Terminal • { • TerminalId terminalId; • public: • Terminal(TerminalID terminalId); • ~Terminal(); • Status handleRunDiagnostics(); • Status handleOutOfService(); • Status handleInService(); • };
  • 108. Design Patterns Exemplo • Manager Design Pattern (cont 9/9) – Known Uses • The manager design pattern is used wherever there is a need to manage multiple objects of same or similar behavior. – Related Patterns • Feature Design Patterns like parallel and serial coordination.
  • 109. Design Patterns - Exercício • Identificar e descrever os design patterns utilizados no projeto, apresentando o racional de uso; • Identificar e descrever a possibilidade de uso de design patterns no projeto, defendendo o porque da escolha e os impactos da mudança no projeto; • Extra: identificar novos padrões (designs que podem ser reutilizados em outros projetos) e descrevê-los de acordo com o template apresentado anteriormente;
  • 110. Universidade Positivo Especialização em Engenharia de Software Práticas de Desenvolvimento de Software Tiago Barros | tiago@tiagobarros.org