Fundamentos de Engenharia de

Software

Prof. Carlos Padovani

cpadovani@fatecbt.edu.br

1
 Significado
• Engenharia
– É o conjunto de atividades e funções de
um engenheiro, que vão da concepção e
do planejamento até a responsabilidade
pela construção e pelo controle dos
equipamentos de uma instalação técnica
ou industrial.

Fonte: Dicionário Houaiss 2

 Definição
• Engenharia de software é uma área do
conhecimento da informática voltada
para a especificação, desenvolvimento
e manutenção de sistemas de software
aplicando tecnologias e práticas de
ciência da computação, gerência de
projetos e outras disciplinas,
objetivando organização, produtividade
e qualidade.

3
 Definição
• Atualmente, essas tecnologias e
práticas englobam linguagens de
programação, bases de dados,
ferramentas, plataformas, bibliotecas,
padrões, processos e a questão da
Qualidade de Software.

4
 Definição

• Os fundamentos científicos para a

engenharia de software envolvem:
– uso de modelos abstratos e precisos que
permitem ao engenheiro:
• especificar, projetar, implementar e
manter sistemas de software, avaliando
e garantindo suas qualidades.
• Além disso, oferecer mecanismos para
se planejar e gerenciar o processo de
desenvolvimento.

5
 Sistema

• A palavra sistema é definida no

dicionário da língua portuguesa como
“um conjunto de elementos concretos
ou abstratos entre os quais se pode
encontrar alguma relação”

6
 Sistema

• Um conjunto, identificável e coerente,

de elementos que interagem
coesivamente, onde cada elemento
pode ser um sistema

7
 Sistema
Exemplo

•Sistema de reservas de passagem aérea

• Fronteira conceitual: companhia aérea
• Dados sobre os vôos
• Disponibilidade, reserva, cancelamento,
etc.

8
Categorias de softwares

• Sistemas Genéricos
• Sistemas Específicos

9
Produto de software

• Instruções (programas de computador)

• Estruturas de dados
• Documentos

10
Começo da vida de um software

• Alto índice de erros

• Correção – estabilização do índice
• Introdução de mudanças - deteriorização

11
Pontos importantes da construção de um

software

• 1 - Construído de acordo com as necessidades

do usuário.

• 2 - Software reutilizável.

12
Processo de desenvolvimento de um
software:

• 1 - Desenvolvimento: as funcionalidades
e as restrições à operacionalidade do
produto são especificadas e produzidas

13
Processo de desenvolvimento de um
software:

• 2 - Validação: o produto de software é

validado para garantir que ele faça
exatamente o que o usuário deseja

14
Processo de desenvolvimento de um
software:

• 3 - Manutenção: o software sofre

correções, adaptações e ampliações para
corrigir erros encontrados após a entrega
do produto (novos requisitos e novas
tecnologias)
15
 Engenharia de software
• Atributos a serem considerados em um
produto de software:
• Complexidade
• Visibilidade
• Aceitabilidade
• Confiabilidade
• Manutenibilidade
• Segurança
• Acessibilidade
16
 Engenharia de software

• Exemplos de atributos a serem considerados:

• Sistema de controle de tráfego aéreo:
• Confiabilidade
• Sistema de controle de eletrodomésticos:
• Desempenho

17
 Engenharia de software - Princípios

• Formalidade
• Abstração
• Decomposição
• Generalização
• Flexibilização

18
 Engenharia de software - Princípios

• Formalidade:
• Criatividade x Formalidade
• Produto = realidade das necessidades

19
 Engenharia de software - Princípios

• Abstração
• Processo de identificação dos aspectos
importantes de um determinado fenômeno
• Diferentes abstrações da mesma realidade,
cada um fornecendo uma visão diferente

20
 Engenharia de software - Princípios

• Decomposição
• A complexidade sendo tratada por meio da
subdivisão do processo em atividades
específicas

21
 Engenharia de software - Princípios

• Generalização
• Possibilidade que a solução para o
problema tenha potencial para ser reutilizada
• Sistema específico para um genérico, mais
amplo (Exemplos: biblioteca, acadêmico)

22
 Engenharia de software - Princípios

• Flexibilização
• Permitir que o produto possa ser modificado
com facilidade.

23
 Paradigmas

• São modelos de processo que possibilitam:

• Ao gerente controlar o processo de
desenvolvimento
• Ao desenvolvedor obter a base para
produzir, de maneira eficiente, software que
satisfaça os requisitos preestabelecidos

24
 Paradigmas

• Função:
• Diminuir os problemas encontrados no
processo de desenvolvimento do software.

25
 Paradigmas
• Ciclo de vida clássico (sistemático e seqüencial)

26
 Paradigmas

• Ciclo de vida clássico

• 1 - Análise e especificação de requisitos
• Especificação dos requisitos, sem
especificar como esses requisitos serão
obtidos.

27
 Paradigmas

• Análise e especificação de requisitos

• Produtos:
• Requisitos funcionais – descrevem o que o produto
de software faz.
• Requisitos não funcionais – podem ser
classificados nas categorias confiabilidade
(disponibilidade, integridade, segurança), acurácia dos
resultados, desempenho, problemas de interface
homem-computador, restrições físicas e operacionais,
questões de portabilidade, etc.

28
 Paradigmas

• Análise e especificação de requisitos

• Produtos:
• Requisitos de desenvolvimento e manutenção –
incluem procedimentos de controle de qualidade –
particularmente procedimentos de teste do sistema -,
prioridade das funções desejadas, mudanças prováveis
nos procedimentos de manutenção do sistema e outros

29
 Paradigmas
• Ciclo de vida clássico
• 2 - Projeto
• Representação das funções do sistema
em uma forma que possa ser
transformada em um ou mais programas
executáveis.
• Produto: documento de especificação de
projeto

30
 Paradigmas

• Ciclo de vida clássico

• 3 - Implementação e teste unitário
• Projeto do software é transformado em
um programa, ou unidades de programa,
em uma determinada linguagem de
programação

31
 Paradigmas

• Ciclo de vida clássico

• 4 - Integração e teste do sistema
• Programas ou unidades de programas
são integrados e testados como um
sistema completo para garantir que todos
os requisitos sejam satisfeitos

32
 Paradigmas

• Ciclo de vida clássico

• 5 - Operação e manutenção
• Fase mais longa do ciclo de vida.
• O sistema é instalado e colocado em uso.
• Manutenção (corretiva, adaptativa,
evolutiva e preventiva).

33
 Paradigmas

• Estudo de viabilidade
• Evitar de gastar tempo solucionando o
problema errado
• Objetivo: relação custos e benefícios
• Documento contendo:
• Definição do problema
• Soluções alternativas, com benefícios esperados
• Fontes necessárias, custos e datas de entrega

34
 Paradigmas

• Ciclo de vida clássico

• Outras atividades:
• Estudo de viabilidade.
• Documentação.
• Verificação e Validação.
• Gerenciamento.

35
 Paradigmas

• Documentação
• Verificação e Validação
• Processo de controle de qualidade
• Objetivo: monitorar a qualidade do produto durante o
desenvolvimento

• Gerenciamento
• Controlar o processo de desenvolvimento
• Gerenciamento de recursos materiais e humanos

36
 Paradigmas

• Ciclo de vida clássico

• Contribuições:
• O processo de desenvolvimento de
software deve ser sujeito à disciplina,
planejamento e gerenciamento
• A implementação do produto deve ser
postergada até que os objetivos tenham
sido completamente entendidos
37
 Paradigmas

• Ciclo de vida clássico

• Problemas:
• Rigidez
• Detecção de erros posteriormente
• Demora na entrega do produto final
(alterações de requisitos)

38
 Paradigma Evolutivo

• Desenvolvimento Exploratório

39
 Paradigma Evolutivo

• Protótipo descartável

• Objetivo: entender os requisitos do usuário e, consequentemente,

obter uma melhor definição dos requisitos do sistema

40
 Paradigma Espiral
• Tenta englobar as melhores característica:
• Ciclo de Vida Clássico + Paradigma Evolutivo

+
ANÁLISE DE RISCO

Risco: circunstâncias adversas que podem atrapalhar o

processo de desenvolvimento e a qualidade do produto a
ser desenvolvido

41
• Paradigma Espiral

42
Áreas que influem e são influenciadas
na Engenharia de Software
• Teoria da computação
• Semântica formal
• Ex: Regras de controle de linha do trem
• Linguagens de programação
• Modularização/bibliotecas
• Desenvolvimento de compiladores
• Sistemas Operacionais

43
Áreas que influem e são influenciadas
na Engenharia de Software
• Banco de dados
• Gerenciamento de acesso concorrente
• Linguagem SQL
• Sistemas multiagentes (decomposição)
• Sistema de processamento de Textos (análise
sintática, semântica, pragmática, etc)
• Sistemas especialistas

44
EXTRAÇÃO DE REQUISITOS
Parte 2

45
 Paradigmas
• Ciclo de vida clássico (sistemático e seqüencial)

46
 Extração de requisitos

• Requisito

• Condição necessária para a obtenção de

certo objetivo.

• Funcionais e Não-funcionais (restrições)

47
 Extração de requisitos

• É o processo de transformação das idéias que

estão na mente dos usuários (a entrada) em um

documento formal (a saída).

• Este documento deve determinar os

OBJETIVOS/FUNÇÕES e as RESTRIÇÕES do

software.

48
 Estudo de Caso
• Gostaria que fosse construído um sistema para monitorar a
temperatura e a pressão de pacientes UTI, que deverão ficar
ligados on-line à rede de computadores do hospital, que é
formada por um computador principal e vários terminais que
monitoram os pacientes. Se a temperatura ou pressão do
paciente lida pelo terminal se tornarem críticas, o computador
principal deverá mostrar uma tela de alerta com um histórico
das medidas realizadas para o paciente. Um aviso sonoro
deve ser ativado nesse caso.
•A verificação da pressão é feita comparando-se a pressão
do paciente com um valor padrão de pressão (máximo e
mínimo) a ser digitado pelo responsável e verificando-se se a
pressão medida está dentro dos parâmetros considerados
normais para o paciente (valores próximos ao máximo e
mínimo são permitidos). Temos vários sistemas on-line no
computador e todos devem rodar ao mesmo tempo.

49
 Estudo de Caso

• Gostaria que fosse construído um sistema para monitorar a

temperatura e a pressão de pacientes UTI, que deverão ficar
ligados on-line à rede de computadores do hospital, que é
formada por um computador principal e vários terminais que
monitoram os pacientes. Se a temperatura ou pressão do
paciente lida pelo terminal se tornarem críticas, o computador
principal deverá mostrar uma tela de alerta com um histórico
das medidas realizadas para o paciente. Um aviso sonoro
deve ser ativado nesse caso. A verificação da pressão é feita
comparando-se a pressão do paciente com um valor padrão
de pressão (máximo e mínimo), a ser digitado pelo
responsável e verificando-se se a pressão medida está
dentro dos parâmetros considerados normais para o paciente
(valores próximos ao máximo e mínimo são permitidos).
Temos vários sistemas on-line no computador e todos devem
rodar ao mesmo tempo.

50
 Estudo de Caso
• FUNÇÕES (requisitos funcionais):
• Monitorar temperatura e pressão;
•Controle temp. e pressão (máximo e mínimo),
providenciar um aviso sonoro de temperatura e
pressão críticas.
• Entrada de pressão e temperatura máx e min.

• RESTRIÇÕES (requisitos não-funcionais):

• O sistema deve ser on-line;
• Banco de dados central;
• O sistema deve rodar ao mesmo tempo que outros,
necessitando, portanto, de controle de concorrência;
• O aviso deve ser sonoro.

51
 Extração de requisitos

• Objetivo: documento de especificação dos

requisitos

Descreve “o que” o produto a ser desenvolvido

deverá fazer.
... e não “como” deve ser feito.

52
 Extração de requisitos

Fases:

• Entendimento do domínio

• Extração e análise de requisitos

• Especificação dos requisitos

• Validação dos requisitos

53
 Extração de requisitos
Dificuldades:
• Quanto mais complexo for o produto, mais
difícil se torna o processo.
• Complexidade pode ser tratada com o
princípio da decomposição.

54
 Extração de requisitos
Dificuldades:
• Falta de conhecimento do usuário das suas reais
necessidades.
• Falta de conhecimento do desenvolvedor do
domínio do problema.
• Domínio do processo de extração pelos
desenvolvedores.
• Comunicação inadequada entre desenvolvedores
e usuários (mal-entendido entre usuários e desenvolvedores)

55
 Extração de requisitos
Dificuldades:
• Dificuldade de o usuário tomar decisões.
• Problemas de comportamento (omissão de
requisitos por insegurança dos usuários).

• Questões técnicas (requisitos obsoletos).

56
 Extração de requisitos

Participantes:

• Desenvolvedor.

• Usuários que conheçam o domínio ou o

ambiente.

57
 Extração de requisitos

Técnicas – procedimentos genéricos:

• Perguntar sobre os requisitos.

• Observar e inferir suas necessidades.
• Discutir e formular.
• Negociar.
• Estudar e identificar problemas.
• Supor (produto novo ou usuário ausente).

58
 Extração de requisitos
Técnicas informais:
Entrevistas

Fases:
1. Identificação dos candidatos para entrevista.
2. Preparação para uma entrevista.
3. Condução da entrevista.
4. Finalização da entrevista.

59
 Extração de requisitos
Técnicas informais:
Brainstorming
Fases:
1. Geração de idéias.
2. Consolidação de idéias (filtragem).

Participantes.

Finalidade:
Geração de visões do problema.

60
 Extração de requisitos
Técnicas informais:
Brainstorming

Fases:
1. Geração de idéias.
• Proibido criticar as idéias.
• Número grande de idéias.
• Estímulo à idéias não convencionais.
• Estímulo a enriquecer outras idéias.

61
 Extração de requisitos
Técnicas informais:
Brainstorming

Fases:
2. Consolidação das idéias.
• Organização.
• Revisão e esclarecimento.
• Adoção, junção e descarte.
• Priorização.

62
 Extração de requisitos
Técnicas informais:
Brainstorming

Vantagens:
1. Estimula o pensamento imaginativo.
2. Interação social.
3. Fácil implementação e baixo custo.

Desvantagem:
1. Processo não estruturado (baixa qualidade).

63
 Extração de requisitos
Técnicas informais:
Pieces
Ajuda na formulação das perguntas.

Sigla de:
• Desempenho (performance).
• Informação e dados.
• Economia.
• Controle.
• Eficiência.
• Serviços.
64
 Extração de requisitos
Pieces
Desempenho (performance).

• Número de tarefas completadas / tempo

(throughput).
• Tempo de resposta.

65
 Extração de requisitos
Pieces
Informação e dados.

• Forma e a maneira correta na geração e

acesso aos dados e informação.

66
 Extração de requisitos
Pieces
Economia.

• Custo de usar um software.

• Redução dos recursos empregados para
gerar trabalho útil.

67
 Extração de requisitos
Pieces
Controle.

• Alerta de erros.
• Segurança – Controle de acesso.
• Auditoria.

68
 Extração de requisitos
Pieces
Eficiência.

• Relação entre energia e os recursos

aplicados que resultam em trabalho útil.

69
 Extração de requisitos
Pieces
Serviços.

• Quais tipos de serviços o software deve

oferecer.

70
 Extração de requisitos
Técnicas informais:
JAD (Joint Application Design)
Promover cooperação, entendimento e trabalho
em grupo.

Princípios:
1. Dinâmica de grupo.
2. Uso de técnicas visuais.
3. Manutenção do processo organizado e racional.
4. Utilização de documentação-padrão que é
preenchida e assinada por todos os participantes.

71
 Extração de requisitos
Técnicas informais:
JAD (Joint Application Design)
Participantes:
1. Líder (facilitador).
2. Engenheiro de requisitos.
3. Executor.
4. Representantes dos usuários.
5. Representantes de produtos de software.
6. Especialista.

72
 Extração de requisitos
Técnicas informais:
JAD (Joint Application Design)
Fases:
1. Adaptação.
2. Sessão (definir objetivos, benefícios, estratégias,
restrições, segurança, auditoria, controle e o
escopo).
3. Finalização

73
 Extração de requisitos
Técnicas informais:

Prototipagem

74
 Extração de requisitos
Importância:

75
Modelos para especificação de sistemas
de software – Projeto
Parte 3
Modelo de função:
- DFD (Diagrama de Fluxo de Dados)
- UML (Unified Modeling Language)
É uma linguagem de modelagem não proprietária de terceira geração.
A UML não é uma metodologia de desenvolvimento, o que significa
que ela não diz para você o que fazer primeiro e em seguida ou
como projetar seu sistema, mas ela lhe auxilia a visualizar seu
desenho e a comunicação entre objetos.

76
Modelos para especificação de sistemas
de software – Projeto
Parte 3
Modelo de dados:
- DER / MER (Modelo Entidade
Relacionamento)

77
 Implementação de Software
Parte 4

Referência bibliográfica:
Livro: Introdução a Informática Autor: Peter Norton
Capítulo: 13 – p. 442 - 491

78
 Implementação de Software

•Etapas que antecedem a Implementação:

• Projeto
• Fluxograma
• Português Estruturado (algoritmo)

79
 Implementação de Software

Fluxograma

80
 Implementação de Software

•Etapa de Implementação:
• Fase que ocorre a materialização de um
projeto de software.
• Onde o projeto é codificado em uma
determina linguagem.

81
Implementação de Software

• Linguagens:
• Baixo nível
• Alto Nível

82
 Implementação de Software

Linguagem
Estruturada
(código-fonte)

•Rotinas:
•Procedimentos
•Funções

83
 Implementação de Software

•Linguagens (quanto a geração do executável)

• Interpretadas (execução linha a linha)

• Funcionamento
• Exemplos: BASIC , Bash, Perl, PHP, Asp, Python,
Euphoria, Forth, JavaScript, Logo, Lisp, Lua, MUMPS,
Ruby, Haskell, etc.

84
 Implementação de Software

•Linguagens (quanto a geração do executável)

• Montadas

• Funcionamento
• Exemplo: Assembly

85
 Implementação de Software

•Linguagens (quanto a geração do executável)

• Compiladas

• Funcionamento
• Exemplos: Cobol, Fortran, C, Pascal, VB, Clipper,
Dataflex, Java, etc.

86
Implementação de Software
Linguagens compiladas

87
Implementação de Software

Linguagem Assembly

88
 Implementação de Software

Linguagem
Fortran

89
 Implementação de Software

Linguagem
Cobol

90
 Implementação de Software

Linguagem
Basic

Basic: Beginners All-purpose Symbolic Instruction Code

91
 Implementação de Software

Linguagem
...
Pascal

92
 Implementação de Software

Linguagem
C

93
 Implementação de Software

Linguagem
C++

POO

94
 Implementação de Software

• Outras linguagens:
• Win32 / Client-Server:
• Object Pascal (Delphi).
• Visual Basic
• Internet:
• ASP
• Html ???
• PHP

95
 Implementação de Software

• Funcionamento:
• Win32 x Internet

96
 Implementação de Software
• Outras linguagens:
• JAVA
• Criação: Sun Microsystems - 1991
• Alto nível – similar ao C++
• POO
• Independência de plataforma (portabilidade)
• JVM (Java Virtual Machine)

97
 Implementação de Software
• JAVA e .NET
• Bytecode
• Resultado de um processo semelhante ao
dos compiladores de código-fonte que não é imediatamente
executável.
• bytecode será interpretado em uma máquina virtual, que fará a
execução.
• bytecode é um estágio intermédio entre o código-fonte e
a aplicação final.

98
 Borland Delphi
• Não é apenas uma linguagem de
programação, mas um ambiente de
desenvolvimento integrado
– acesso a um editor de códigos
– ferramenta para construção da
interface gráfica
• formulários;
• botões;
• caixas de texto;
• menus;
• etc.
99
 Inprise/Borland Delphi
4.0
• Linguagem Object Pascal
• Aplicações “visuais” com o uso de
componentes
• Componentes possuem
– Propriedades (properties)
– Métodos (methods)
– Eventos (events)
• Orientação a Objetos (OO) e
Eventos
100
 Ambiente

Janela
Principal

Object
Inspector Form1

101
 Ambiente
1) Janela Principal
Barra de título
Barra de menu

Caixa de Paleta de
Ferramentas componentes
102
 Ambiente
2) Object Inspector

 Acesso direto às
propriedades e eventos
relacionados a um
componente ou
formulário.

103
 Ambiente
3) Form1
– Formulário default, criado
automaticamente pelo Delphi
– O que o Delphi chama de formulário, é
na verdade uma janela de uma
aplicação Windows.

104
 Ambiente
4) Editor de Código (Code Editor)
• Linguagem
Object Pascal;
• Normalmente não
está visível;
• Já cria
automaticamente
uma unidade de
código (unit)
default.

105
 Ambiente
5) Janela de
Exploração de
Código (Code
Explorer)
– Acesso direto a vários
trechos do programa
(unit)
– Situada à esquerda
do Code Editor

106
 Ambiente
• É no Editor de Códigos que você digitará os
comandos em Pascal. O Delphi já acrescenta
algumas linhas de código automaticamente.
• A criação da interface gráfica é apenas uma das
etapas necessárias à criação do aplicativo.
• É através dos códigos de programa que
conseguimos que a nossa aplicação se
comporte como desejamos.
• O objetivo das ferramentas visuais de
programação é simplificar o desenvolvimento
da interface.

107
 Ambiente
• Uma aplicação no Delphi
contém
– Projetos *.dpr, que Project1.dpr
contém...
– Unidades de código *.pas
unit1.pas
(UNITs), que possuem...
unit1.dfm

– Formulários (Forms) unit2.pas

relacionados, que estão unit2.dfm
definidos em arquivos unit3.pas
´nome_unit.dfm´ unit3.dfm

108
 Caixa de Ferramentas
Gravar tudo Adicionar/Remover
Abrir... arquivos no Projeto
Abrir
Novo... Gravar Projeto...
Ajuda

Lista de Novo Form Pausa

UNITs
Alterna
Lista de UNITForm Executa!
Forms

109
 Object Pascal
unit Unit1;
Estrutura de um interface
programa uses Windows, Messages, SysUtils, Classes,
Graphics, Controls, Forms, Dialogs;
Seção de type
interface do TForm1 = class(TForm)
private
código { Private declarations }
public
{ Public declarations }
end;
Definição de
classes var Form1: TForm1;

implementation
{$R *.DFM}
Seção de
end.
implementação
110
 Object Pascal
• Diretivas de Programação
– usadas para habilitar/desabilitar opções
do compilador
– são definidas em Project/Options
– ex: { $R *.DFM }
• diz que as propriedades do formulário
serão armazenadas em um arquivo
*.dfm (com o mesmo nome dado a
UNIT: unit1.pas => unit1.dfm)

111
 Revisão de Pascal
• Comentários
{...}, (* ... *)
• uses
– especifica as unidades de código (units)
que serão usadas
• type
– definição de novos tipos e classes de
objetos
• var
– declaração de variáveis: integer, byte,
longint, word, char, boolean, string,
widestring, real, single, double, extended,
variant (qualquer tipo!)
112
 Pascal
• Estruturas de Controle
–Sequência
–Condição (se...então)
–Repetição (enquanto...)

113
 Pascal
• Estruturas Condicionais (IF)

simples composta
if condicao then if condicao then
bloco; bloco1
else
bloco2;

114
 Pascal
• Algumas funções pré-definidas
– date (conforme armazenado no
sistema)
– time (conforme armazenado no
sistema)
– datetostr
– datetimetostr
– inttostr
– strtoint
– floattostr
– strtofloat
115
 OO
• Programação OO (Orientada a
Objetos)
– Os objetos são a base da tecnologia
– Consistem de modelos (abstrações) de
objetos reais
– Preservam as características essenciais
de um objeto real: suas propriedades e
seu comportamento (métodos)
• Exemplos de linguagens OO
– Simula 67’, Smalltalk, C++, Delphi,
Java, etc.
116
 OO
• O que é um Objeto ?
– é a representação de um objeto real
– é uma abstração
– tudo que é manipulável e/ou
manufaturável
– coisa, peça, artigo de compra e venda
– pode ser uma composição de outros
objetos
• Exemplos
• automóvel, pessoa, elevador, janela,
etc..
117
 OO
1) Propriedades de um Objeto
– é o estado do objeto
– são atribuitos da “coisa”
– exemplo
• Em um automóvel temos
–ligado/desligado
–posição
–velocidade
–marca/modelo
–cor, placa, número de portas, etc.

118
 OO
2) Métodos de um objeto
– representa o comportamento do objeto
– muda o estado do objeto
– exemplo
• Em um automóvel temos
–ligar/desligar
–acelerar
–freiar
–virar p/ esquerda
–virar p/ direita

119
 OO
3) Eventos de um Objeto
– são acontecimentos que fazem o objeto
responder de determinada maneira
– alteram o estado e mudam o
comportamento
– exemplo
• Em um automóvel temos
– usuário...
» pisa no acelerador ou no freio
» vira o volante para esquerda ou
direita
» vira a chave na ignição para ON
ou OFF
120
 OO
• Classe de Objetos
– Definição de um tipo de objetos
– Define a forma de se criar objetos
– É uma fábrica de objetos
– Todos os objetos de uma classe têm uma
estrutura idêntica, mas cada objeto terá
seus próprios atributos
– Exemplo
• Classe: CARROS (cor, portas, placa, posição,
velocidade, etc.)
• Objeto: carro vermelho/2
pts/XXX9999/(100,10)/100km/h...

121
 OO
• Porque usar Objetos ?
– Simplicidade: os objetos escondem a
complexidade do código. Pode-se criar
aplicações sem se conhecer a
complexidade do código.
– Reutilização de código: um objeto,
depois de criado, pode ser reutilizado por
outras aplicações, e até extender suas
funções.
– Inclusão dinâmica: objetos podem ser
incluídos dinâmicamente durante a
execução, reduzindo o tamanho do arquivo
final.
122
 OO
• Princípios básicos de uma linguagem
OO
1) Abstração
– é o processo de extrair as
características essenciais de um objeto
– a abstração de um objeto é diferente de
acordo com a visão de cada pessoa
– ex: livro
Livraria: autor, título, assunto, editora, preço
Transportadora: número de páginas, formato e
tipo de capa (=>peso)
123
 OO
• Princípios básicos de uma linguagem OO
(cont.)
2) Encapsulamento
– é o processo de combinar dados e funções
relacionadas em um único objeto
– agrupa o estado do objeto e as funções que
ele é capaz de executar, e que alteram seu
próprio estado
– esconde a complexidade do código
– exemplo: radio.ligar := true;
radio.gravar(musica);

124
 OO
• Princípios básicos de uma linguagem OO
(cont.)
3) Herança
– é o aproveitamento e extensão das
características de uma classe existente
– uma classe mais sofisticada herda as
características e funcionalidades de uma classe
básica
– exemplo: Classe CARROS_ESPORTIVOS
como herança da Classe CARROS
* Novos Atributos: turbo, barra de
proteção, rádio intercomunicador, temperatura do
óleo, etc.
125
 OO
• Princípios básicos de uma linguagem OO
(cont.)
4) Polimorfismo
– é a propriedade de se utilizar um mesmo
nome ou forma para fazer coisas diferentes
– muito útil para escrever programas
versáteis, que possam lidar com vários tipos
diferentes de objetos
– exemplo: triângulo.Desenhe;
retângulo.Desenhe; Sobreposição
círculo.Desenhe; de métodos
reta.Desenhe;

126
Paradigmas

127
 Paradigmas

POG
PROGRAMAÇÃO ORIENTADA A GAMBIARRAS

128
 Paradigmas

• Fatores Favoráveis:
• Sistemas originalmente mal projetados.
• Clientes chatos.
• Falta de vontade.
• Falta de tempo.
• Gente que pensa que é DBA.
• Arquiteto de software achando que é o
máximo.
129
 Paradigmas

• Fatores Favoráveis:
• Término do estoque de café.
• Aproximação do final da tarde.
• Véspera de feriado/fim de semana.
• Ter o Jackie Chan como chefe.
• Ter o MacGyver como coordenador.
• Governo descarregando regras ou MPs que entram
em vigor imediatamente.
• Requisitos dinâmicos.

130
 Paradigmas

• Princípios da POG:
• Se funciona então tá certo.
• Deixe o amanhã para amanhã.
• Comentários são para amadores.
• Fé em Deus.
• 1337 H4XOR5 DUD3 LOL.
• Capacidade de abstração.
• Murphy.

131
Paradigmas

132