Engenharia de Software

Thiago M. B. Rodrigues

Engenharia de SW

uma disciplina da engenharia que se ocupa de

todos os aspectos da produo de software, desde
os estgios iniciais de especificao do sistema at
a manuteno desse sistema, depois que ele entrou
em produo. Sua meta o desenvolvimento de
sistemas de Sw com boa relao custo-benefcio.

Evoluo da ESW

Iniciou em 1968: crise do software

Dcada de 1970: Programao Estruturada e Projeto

Estruturado

Dcada de 1980: Anlise Estruturada (surgimento

de ferramentas CASE)

Dcada de 1990: Anlise e Projeto Orientados a

Objetos

Dcada de 2000: SOA

Conceitos

Software (lato sensu): programas de computador +

dados + documentao associada

Processo de Software: um conjunto de atividades,

cuja meta o desenvolvimento ou a evoluo do
software

Essncia da ESW

Entenda o problema: levantamento de requisitos e

anlise.

Planeje uma soluo: projeto.

Execute o plano: implementao.

Examine o resultado quanto a preciso: teste e

garantia de qualidade.

Modelo em Cascata

Fases clssicas no desenvolvimento

de Software
Levantamento
de
Requisitos:
propiciar
que
usurios
e
desenvolvedores tenham a mesma compreenso do problema a ser
resolvido.
Anlise: construir modelos que determinam qual o problema para o
qual estamos tentando conceber uma soluo de software.
Projeto: estgio no qual o modelo de anlise ter de ser adaptado de
tal modo que possa servir como base para implementao no ambiente
alvo.
Codificao (implementao):
efetivamente executada.

codificao

Teste: consiste na verificao do software.

Implantao: entrada em produo do sistema.

do

sistema

Modelo Incremental

Modelos Evolucionrios Prototipagem

Auxilia o engenheiro de software e o cliente a

entenderem melhor o que deve ser construdo
quando os requisitos esto confusos.

O prottipo serve como um mecanismo para a

identificao dos requisitos de software.

Modelos Evolucionrios Prototipagem

Modelos Evolucionrios - Espiral

O software desenvolvido numa srie de verses

evolucionrias.

Modelo de Mtodos Formais

Baseados em modelos matemticos.

Lento e dispendioso.

Necessita treinamento extensivo.

Clientes despreparados no entendem.

Dificultando a comunicao.

Ideal para modelar Sistemas Crticos.

Desenvolvimento gil

Agilidade:
capacidade

de responder adequadamente
modificaes/mudanas:
modificaes

no software;

modificaes

nos membros da equipe;

modificaes

devido a novas tecnologias; etc.

Desenvolvimento gil

Requisitos e prioridades instveis (volteis).

Projeto e construo so realizados

simultaneamente.

Anlise, projeto, implementao e testes no so

to previsveis (planejamento).

Modelos geis

XP - Extreme Programing.

Scrum.

ASD - Adaptative Software Development.

DSDM - Dynamic Systems Development Methed.

Crystal.

FDD - Feature Driven Development.

O Manifesto gil
Estamos evidenciando maneiras melhores de desenvolver
software fazendo-o ns mesmos e ajudando outros a faz-lo.
Atravs desse trabalho, passamos a valorizar:

Indivduos e interao MAIS QUE processos e ferramentas;

Software em
abrangente;

Colaborao com o cliente MAIS QUE negociao de contratos;

Responder a mudanas MAIS QUE seguir um plano.

funcionamento

MAIS

QUE

documentao

Mesmo tendo valor os itens direita, valorizamos mais os itens

esquerda.

EXTREME PROGRAMMING - XP

Desenvolvida em 1996 por Kent Beck, uma metodologia bastante

nova que renega todos os paradigmas do desenvolvimento
tradicional de software. Para a XP, a arquitetura do sistema uma
metfora. A arquitetura na verdade desenvolvida ao longo do
projeto onde todo o cdigo escrito constantemente reconstrudo
para aumentar a simplicidade e objetividade do mesmo. A XP vem
ganhando inmeros adeptos dentre os programadores mais
experientes.

Metodologia adequada a equipes pequenas (at 10 pessoas), parte

do princpio de que a melhor documentao o cdigo fonte:
qualquer outra documentao fica logo desatualizada e por isso
perde a confiabilidade.

EXTREME PROGRAMMING - XP

Baseada em prticas, como programao aos pares,

semana de 40 horas e reunies em p.

Frases conhecidas:
Sem

um processo, s uma pessoa excepcional

consegue desenvolver um sistema. Com muitos
processos, pessoas excepcionais no conseguem
desenvolver sistemas excepcionais.

Uma

boa equipe pequena produz mais que

grandes equipes.

As Prticas do XP

The Customer is Always Available - O cliente est sempre

disponvel para resolver dvidas, alterar o escopo de uma
iterao e definir prioridades.

Metaphor - O time se comunica sobre o software em termos

de uma metfora, caso consiga encontrar uma boa.

Small Releases - O software entregue em pequenas

verses para que o cliente possa obter o seu ganho o mais
cedo possvel e para minimizar riscos.

Acceptance Tests - So definidos pelo usurio e so os

critrios de aceitao do software.

As Prticas do XP

Test First Design - Primeiro so escritos os testes, depois

feita a implementao e por ltimo trabalha-se o design.

Continuous Integration - Os diversos mdulos do software so

integrados diversas vezes por dia e todos os testes unitrios
so executados. O cdigo no passa at obter sucesso em
100% dos testes unitrios.

Simple Design - O cdigo est, a qualquer momento, na forma

mais simples que passe todos os testes.

Refactoring - A cada nova funcionalidade adicionada,

trabalhado o design do cdigo at ficar na sua forma mais
simples.

As Prticas do XP

Pair Programming - Todo cdigo de produo

desenvolvido por duas pessoas trabalhando com o
mesmo teclado, o mesmo mouse e o mesmo monitor.

Collective Code Ownership - E equipe como um todo

responsvel por cada arquivo de cdigo. No preciso
pedir autorizao para alterar qualquer arquivo.

Coding Standards - Todo cdigo desenvolvido seguindo

um padro.

40 Hour Week - Trabalhar por longos perodos

contraproducente.

XP - Valores

Comunicao.

Simplicidade.

Feedback.

Coragem.

Respeito.

XP - Princpios bsicos

Feedback rpido.

Presumir simplicidade.

Mudanas incrementais.

Abraar mudanas.

Trabalho de alta qualidade.

Scrum

Princpios de Programao
Orientada a Objetos - OOP

Um objeto a representao computacional de um elemento

ou processo do mundo real.

Cada objeto possui suas caractersticas (atributos) e seu

comportamento (mtodos).

Exemplos de Objetos:

Aluno

Disciplina

Estado

Pessoa

Princpios de Programao
Orientada a Objetos - OOP

Princpios de Programao
Orientada a Objetos - OOP

Mensagens:

Um programa OO um conjunto de objetos que colaboram entre

si para a soluo de um problema

Objetos colaboram atravs de trocas de mensagens

A troca de mensagem representa a chamada de um mtodo

Princpios de Programao
Orientada a Objetos - OOP

Mtodos Especiais:

Criao de Objetos:

A classe responsvel pela criao de seus objetos

Esta criao realizada atravs de um mtodo especial, chamado de

construtor

Eliminao de Objetos:

A classe responsvel pela eliminao de seus objetos, quando

eles no podem mais ser utilizados pelo sistema

Esta eliminao realizada por um mtodo especial, chamado de

destrutor

Princpios de Programao
Orientada a Objetos - OOP

Herana

Classes so organizadas em estruturas hierrquicas:

Uma classe pode herdar caractersticas e comportamento de outras

classes

A classe que forneceu os elementos herdados chamada de superclasse

A classe herdeira chamada de subclasse

A subclasse herda todos os mtodos e atributos de suas superclasses

A subclasse pode definir novos atributos e mtodos especficos

Princpios de Programao
Orientada a Objetos - OOP

Princpios de Programao
Orientada a Objetos - OOP

Interfaces

Uma interface um contrato assinado por uma classe:

A interface define as responsabilidades da classe

As responsabilidades so mapeadas em mtodos abstratos

A classe que implementa a interface implementa os mtodos

Mtodos Abstratos (abstract)

No possuem implementao

Apenas definem um protocolo

So implementados em subclasses

Encapsulamento

Ajuda a esconder detalhes de implementaao.

Mecanismo utilizado para lidar com o aumento de

complexidade.

Consiste em exibir o que pode ser feito sem informar

como feito.

A implementao de um objeto pode ser alterada sem o

conhecimento de seus clientes, desde que a interface visvel
seja mantida.

Encapsulamento

Encapsulamento - Anis de
Operaes

Encapsulamento - Anis de Operaes

Esta tcnica (Anis de Operaes) ajuda a manter um bom

encapsulamento interno da classe.

O uso dessa tcnica no afeta o acesso externo, que continua

sendo regido por modificadores de visibilidade.

Modificadores de visibilidade:

+ Pblico

- Privado

# Protegido

~ De Pacote

Acoplamento

Acoplamento o grau em que uma classe conhece sobre os

membros de outra classe.

Se o nico conhecimento que a classe A tem sobre a classe B,

que a classe B foi exposta atravs de sua interface, ento as
classes A e B so fracamente acopladas, que uma coisa boa.

Se, por outro lado, a classe A se baseia em partes da classe B

que no fazem parte da interface de B, ento elas so
bastante acopladas, o que no uma coisa boa.

Em outras palavras, se A sabe mais do que deveria sobre a

forma como B foi implementada, ento A e B esto bastante
ligadas.

Acoplamento - Observe a Figura

Acoplamento

Como podemos ver na cadeia de classes anterior, o forte

acoplamento na mesma, torna muito custoso a sua manuteno e o
seu gerenciamento, pois qualquer mudana vai afetar toda a cadeia
de classes.

A sada para cenrios como este, o que chamamos de Inverso de

Controle. E uma maneira de mudar o quadro acima, seria inverter o
controle e utilizar o padro de injeo de dependncia, para diminuir
o acoplamento e evitar futuros problemas.

Obseve o diagrama a seguir com as devidas alteraes.

Acoplamento - Observe a Figura

Acoplamento

Perceba como a dependnca est na direo oposta, ou seja, no

mais de implementaes concretas que esto baseados os
relacionamentos entre as classes.

Observe que utilizar abstraes, mantm um cenrio que estar

preparado para os impactos que as possveis mudanas poderiam
trazer.

Repare
que
a
classe
Produto
se
relaciona
com
uma
abstrao( interface ) de DBWrapper, ou seja, tem uma classe
chamada DBWrapperSqlServer que implementa esta interface,
amanh, o banco de dados passar a ser oracle, basta adicionar uma
classe DBWrapperOracle para atender a mudana de banco de dados.

Coeso

Enquanto o acoplamento tem a ver com a forma como as

classes interagem umas com as outras, a coeso sobre
como uma classe projetada.

A coeso indica o grau em que uma classe tem uma finalidade

nica e bem orientada. Isso quer dizer que quanto mais
focalizada for a classe, maior a sua coeso, o que uma coisa
boa.

Coeso

O principal benefcio da alta coeso que normalmente tais

classes so mais fceis de manter (e menos freqentemente
alteradas) do que as classes com baixa coeso.

Outro benefcio da coeso alta que as classes bem

focalizadas tendem a ser mais reutilizadas.

Alta coeso o estado desejvel de uma classe cujos

membros suportam uma nica regra ou responsabilidade bem
focada.

Baixa coeso o estado indesejvel de uma classe cujos

membros suportam mltiplas regras ou responsabilidades
desfocadas.

Coeso
public class Programa {
public void ExibirFormulario() {
//implementao
}
public void ObterProduto() {
//implementao
}
public void gravarProdutoDB {
//implementao
}
}

Coeso
public class Programa {
public void MostrarFormulario() {
//Implementao
}
public void BotaoGravarProduto( ) {
Produto.gravarProduto();
}
}

Engenharia de Requisitos

Engenharia de Requisitos

Etapas da Engenharia de Requisitos:

Concepo

Elicitao

Negociao

Especificao

Validao

Gerenciamento (Rastreabilidade)

Engenharia de Requisitos - Concepo

Objetivo:
Ter

uma viso geral do negcio.

Conhecer

o cliente e suas expectativas.

Resultados esperados:

Identificao dos interessados (stakeholders).

Identificao dos diferentes pontos de vista.

Viso geral do escopo do sistema.

Engenharia de Requisitos Elicitao

Objetivo:

Entender o que o cliente espera do software

Problemas mais comuns:

Escopo varivel (mas contrato fixo)

Incertezas do cliente

Volatilidade dos requisitos

Engenharia de Requisitos Elicitao

Elementos a serem identificados:

Objetos manipulados pelo sistema

Servios prestados pelo sistema

Restries que devem ser obedecidas

Critrios de desempenho

Resultados esperados:

Narrativa em linguagem natural dos requisitos do sistema

Lista de requisitos do sistema

Engenharia de Requisitos Elicitao

Tcnicas de Elicitao:

Entrevistas

Oficinas (workshops)

Reunies de Brainstorming

Prototipao

Maquetes

Anlise de documentao existente

Anlise de sistemas existentes

Observao de pessoas trabalhando (etnologia)

Etc

Engenharia de Requisitos Elicitao

Maximizar a satisfao do cliente!

Requisito normal:

O cliente lembra de falar

O cliente ficar satisfeito se esse requisito estiver no sistema

Requisito esperado:

Requisito implcito

O cliente no lembra de falar

O cliente ficar insatisfeito se esse requisito no estiver no

sistema

Engenharia de Requisitos Elicitao

Requisito excitante:

O cliente no lembra de falar

O cliente no espera encontrar esse requisito no sistema

O cliente ficar satisfeito se esse requisito estiver no

sistema

Engenharia de Requisitos Elicitao

Cliente x Usurio final

Nem sempre o cliente o usurio final

Cliente:

Quem contrata e paga pelo servio

Ex.: Administrador de um hospital

Usurio final:

Quem usa o software no dia a dia

Ex.: Mdicos e enfermeiros

Engenharia de Requisitos Elicitao

Escolha usurios
representativos

fonte

dos

requisitos

que

sejam

Lembre-se que a regra de Pareto (80-20) aparenta ser

vlida:

20% dos requisitos satisfazem a 80% dos usurios

Escolher um usurio muito especialista pode levar

implementao de requisitos que nunca sero utilizados

Engenharia de Requisitos Elicitao

Requisitos Funcionais:

Descrevem as funcionalidades do sistema - o que o sistema deve fazer

Representam as principais funcionalidades do sistema.

Ex.: Criar, Recuperar, Atualizar e Deletar (CRUD) novos alunos

Requisitos no funcionais:

Descrevem a qualidade do sistema

Sinnimo: atributos de qualidade

Restries sobre o modo de operao dos requisitos funcionais

Ex.: Disponibilidade, Eficincia, Velocidade, Portabilidade, etc

Engenharia de Requisitos Negociao

Objetivo:

Priorizar e identificar os riscos dos requisitos

Eliminar, combinar ou modificar os requisitos

Chegar a um consenso sobre a lista final de requisitos

Conflitos comuns:

Requisitos contraditrios

Prioridades

Prazo

Custo

Engenharia de Requisitos Especificao

Objetivo:

Produzir a especificao de requisitos

Descrio detalhada dos requisitos

Produz o documento de requisitos

Especificao de requisito engloba:

Requisitos funcionais

Requisitos no funcionais

Engenharia de Requisitos Validao

Objetivo:

Assegurar que a especificao de requisitos est

consistente

Problemas comuns:

Ambiguidade

Inconsistncia

Omisso

Erro

Engenharia de Requisitos Validao

Exemplos de ambiguidade:

A janela deve abrir rapidamente

O sistema deve ser flexvel

O clculo deve ser eficiente

A interface com o usurio deve ser melhor que a atual

Engenharia de Requisitos Gerenciamento

Objetivo:

Controlar as mudanas nos requisitos

Permitir a anlise de impacto das mudanas

Produz a matriz de rastreabilidade

Tipos de rastreabilidade:

Fonte do requisito

Dependncias entre requisitos

Subsistemas

Interfaces